You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Anil Patel <an...@hotwaxsystems.com> on 2026/06/12 10:36:01 UTC
fulfillment-api: a merchant-facing fulfillment REST API plugin
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
Re: fulfillment-api: a merchant-facing fulfillment REST API plugin
Posted by Anil Patel <an...@hotwaxsystems.com>.
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 <an...@hotwaxsystems.com>
wrote:
> Yes.
> That is correct.
>
>
>
>
> Anil Patel
>
> On Fri, Jun 12, 2026 at 11:07 PM Michael Brohl <mi...@ecomify.de>
> 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
>> >
>>
>
Re: fulfillment-api: a merchant-facing fulfillment REST API plugin
Posted by Anil Patel <an...@hotwaxsystems.com>.
Yes.
That is correct.
Anil Patel
On Fri, Jun 12, 2026 at 11:07 PM Michael Brohl <mi...@ecomify.de>
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
> >
>
Re: fulfillment-api: a merchant-facing fulfillment REST API plugin
Posted by Michael Brohl <mi...@ecomify.de>.
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
>
Re: fulfillment-api: a merchant-facing fulfillment REST API plugin
Posted by Anil Patel <an...@hotwaxsystems.com>.
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 <de...@gmail.com>
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 <
> divesh.dutta@hotwaxsystems.com>
> 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 <anil.patel@hotwaxsystems.com
> >
> > 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
> >
>
Re: fulfillment-api: a merchant-facing fulfillment REST API plugin
Posted by Deepak Nigam <de...@gmail.com>.
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 <di...@hotwaxsystems.com>
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 <an...@hotwaxsystems.com>
> 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
>
Re: fulfillment-api: a merchant-facing fulfillment REST API plugin
Posted by Divesh Dutta <di...@hotwaxsystems.com>.
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 <an...@hotwaxsystems.com>
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