I just added a How to for 3PL setup https://cwiki.apache.org/confluence/display/OFBIZ/How+to+Run+Apache+OFBiz+as+a+3PL+WMS
Thanks and Regards Anil Patel CEO HotWax Systems http://www.hotwaxsystems.com Cell: + 1 509 398 3120 On Sat, Jun 13, 2026 at 5:02 AM Anil Patel <[email protected]> wrote: > 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 >> > >> >
