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
