Yes. That is correct.
Anil Patel On Fri, Jun 12, 2026 at 11:07 PM Michael Brohl <[email protected]> wrote: > Hi Anil, > > just a quick question for clarification: this would be based on the > REST-API which is in the process of being moved to the framework, not > plugin, right? > > Best regards, > > Michael Brohl > > ecomify GmbH - www.ecomify.de > > > Am 12.06.26 um 12:36 schrieb Anil Patel: > > 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 > > >
