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 >
