I started a 3pl-demo component to first configure OFBiz as WMS for  3PL, so
we have something to develop and test the API.

https://github.com/patelanil/ofbiz-plugins/pull/1


Thanks and Regards
Anil Patel
CEO
HotWax Systems
http://www.hotwaxsystems.com
Cell: + 1 509 398 3120


On Fri, Jun 12, 2026 at 6:12 PM Deepak Nigam <[email protected]>
wrote:

> Hi Anil,
>
> Thank you for sharing the proposal.
>
> I think this is a solid proposal that addresses a real need while staying
> aligned with OFBiz’s existing architecture and data model. The design looks
> practical, and having a standard API layer should make integrations much
> easier for external systems and merchant customers.
>
> I support moving this forward and look forward to seeing the implementation
> progress.
>
> Best regards
>
> —
>
> Deepak
>
> On Fri, 12 Jun 2026 at 5:06 PM, Divesh Dutta <
> [email protected]>
> wrote:
>
> > Hi Anil,
> >
> > Thanks for putting together this proposal and sharing the design
> documents.
> >
> > I like the overall direction, particularly the emphasis on reusable
> domain
> > services, declarative REST bindings, tenancy-aware design, and a stable
> > machine-readable error contract. These patterns should provide a solid
> > foundation not only for the fulfillment API but also for future API
> > initiatives within OFBiz.
> >
> > I also appreciate the decision to keep the initial scope focused on the
> > core order lifecycle while intentionally deferring additional
> capabilities
> > such as inventory, returns, and webhooks. Establishing the right
> > architectural patterns first should make it easier to expand the API
> > surface over time without taking on too much complexity in the initial
> > implementation.
> >
> > Overall, I think this is a promising step toward making Apache OFBiz more
> > API-first and integration-friendly, and I look forward to seeing it
> evolve.
> >
> > Thanks
> > --
> >
> > Divesh Dutta
> > www.hotwaxsystems.com
> >
> >
> >
> >
> > On Fri, Jun 12, 2026 at 4:06 PM Anil Patel <[email protected]
> >
> > wrote:
> > >
> > > Hi all,
> > >
> > > I'd like to propose a new plugin for ofbiz-plugins (trunk), working
> name
> > > fulfillment-api.
> > >
> > > This would be OFBiz's REST API built on
> > > the rest-api plugin. It's declarative resource binding, tenancy-checked
> > > domain
> > > services, a stable machine-readable error contract, and a
> > tenant-isolation
> > > test matrix -- that future domain APIs (inventory, party, order
> > management)
> > > can copy.
> > >
> > > The concrete instance is the 3PL scenario. A warehouse operator can run
> > > OFBiz
> > > as a complete WMS today, but has no way to hand merchant customers an
> > API.
> > > OFBiz already models the business with stock entities -- Facility
> > > (ownerPartyId = operator), client-owned InventoryItem.ownerPartyId,
> > > ProductStore as the per-merchant account (payToPartyId = merchant),
> > > OrderHeader with productStoreId and an indexed externalId. What's
> missing
> > is
> > > the machine front door: push orders, poll status/tracking, request
> > > cancellation. The proposed surface:
> > >
> > >   GET  /rest/fulfillment/stores
> >  (discovery)
> > >   POST /rest/fulfillment/stores/{productStoreId}/orders
> (create)
> > >   GET  /rest/fulfillment/stores/{productStoreId}/orders          (poll,
> > > modifiedSince)
> > >   GET  /rest/fulfillment/stores/{productStoreId}/orders/{orderId}
> (detail
> > +
> > > tracking)
> > >   POST
> /rest/fulfillment/stores/{productStoreId}/orders/{orderId}/cancel
> > >
> > > Design stance: OFBiz-native contract; stock data model with zero new
> > tenancy
> > > entities (a merchant is a PartyGroup, access is a ProductStoreRole
> grant,
> > > isolation is a productStoreId filter, idempotency is
> > > OrderHeader.externalId);
> > > two strictly separated layers (testable domain services + a declarative
> > > *.rest.xml binding); multi-merchant from day one; API only, no screens.
> > v1
> > > scope is the order-lifecycle core -- intake, incremental reads, cancel
> --
> > > with item master, inventory, ASN, returns, and webhooks explicitly
> > deferred,
> > > not rejected.
> > >
> > > Design docs for discussion (the case + the architecture/tenancy
> thinking;
> > > the
> > > detailed design and task plan follow as this converges):
> > >
> > > https://cwiki.apache.org/confluence/x/_oSnGQ
> > >
> > > https://cwiki.apache.org/confluence/x/-ISnGQ
> > >
> > >
> > > Thanks
> > >
> > > Thanks and Regards
> > > Anil Patel
> > > CEO
> > > HotWax Systems
> > > http://www.hotwaxsystems.com
> > > Cell: + 1 509 398 3120
> >
>

Reply via email to