Platform
One canonical model, explicit boundaries, recoverable failures.
OneAggrgtr is the layer between the places a merchant sells and the systems that fulfill. Its job is to keep catalog, inventory, order, and fulfillment state consistent, or knowably inconsistent, across systems that were never designed to talk to each other.
Connect commerce channels
Three kinds of boundary. Nothing crosses without one.
Every external system reaches OneAggrgtr through a defined boundary. The direction of the connection is part of the design, not an implementation detail.
Provider adapters
For marketplaces and delivery providers, OneAggrgtr calls out through adapters it owns. Each adapter declares its capabilities explicitly; a write whose capability is not verified is blocked before any call is made.
Integration API
POS partners connect to OneAggrgtr's own API and events, not the reverse. Normalizing partner data is the job of that inbound layer, so the core never depends on a partner's model.
First-party channels
Business-owned websites and apps are intended to be a channel OneAggrgtr owns end to end; none has been built yet. When it exists, it will enter through the same canonical order model as every other source.
Normalize once
Provider identifiers are references, never identity.
A product has one canonical record. Each system that knows it holds its own identifier, recorded as an explicit mapping. Adding a system adds a mapping, not a redesign.
Canonical
Product
One record with its own identity. Name is an attribute, never the identity. Variants, pricing, and inventory hang from it.
- POS partnermasked identifier, External reference
- Marketplace Amasked identifier, External reference
- Marketplace Bmasked identifier, External reference
- First-party channelmasked identifier, External reference
Catalog, not a menu
The core abstraction is industry-neutral. Modifiers are a capability of the model, not its foundation.
CatalogCategoryProductVariant
Orders and fulfillment, apart
Delivery is not just another order status. Fulfillment is its own record with its own lifecycle.
OrderFulfillmentPickup · Delivery · Shipment
Route fulfillment
Four lifecycles that move independently.
A grocery order can be accepted, partly fulfilled, paid, and mid-delivery all at once. One status cannot say that. Separate axes can.
Order
Whether the commerce transaction itself is valid and moving forward.
- Received
- Accepted
- Completed
Terminal exceptions: Rejected · Cancelled · Failed
Fulfillment
How the order is being fulfilled, per fulfillment: pickup, delivery, or shipment. Completion is derived from line-item outcomes such as fulfilled, substituted, or backordered.
- Pickup
- Delivery
- Shipment
Payment
A reference to payment activity that happened elsewhere. OneAggrgtr records it; it does not process payments.
- Authorized
- Captured
- Refunded
Delivery
Status sourced from the delivery provider, when the fulfillment is a delivery.
- Provider-reported
Channel
An order is placed
Ingest
Verified and deduplicated
Canonical order
Received, then accepted
Allocation
Inventory admitted atomically
Fulfillment
Pickup, delivery, or shipment
Reconcile
Unconfirmed outcomes resolved
Cancellation is always honored at the order level. What it does not do is pretend a downstream effect has been undone: if an order had already been sent on, a reconciliation record is opened so the real state is tracked rather than assumed.
Partial fulfillment is normal. An order line can be substituted, backordered, or short without failing the order, and a fulfillment's completion is derived from what actually happened to its lines.
The compensating call to a provider on cancellation is not yet implemented; it depends on provider integrations that do not exist yet.
Synchronize operations
Catalog, inventory, and orders that agree, or say where they do not.
Synchronization is designed so a late, duplicate, or conflicting update is handled deliberately.
Mapping-based catalog sync
A broken product link is caught, not silently wrong. Catalog changes resolve through explicit mappings, and a mapping that is broken, or that points across tenants, opens a reconciliation record instead of failing silently or writing across a boundary.
Atomic inventory reservations
Two orders can never claim the same last unit. Reserving stock is a conditional update, exercised under genuinely concurrent load against a real database.
Ordering guards
Late stock updates do not overwrite newer counts. Each update carries an ordering check applied atomically with the write, so an older update arriving late cannot overwrite a newer one.
These behaviors are exercised against simulated inputs. What a live sync can do with a given provider depends on that provider's verified capabilities, which are treated as unknown until confirmed. See how capabilities are tracked.
Reliability by construction
External systems are unreliable by default. The design assumes it.
Providers can deliver events twice, late, or out of order, and a call can succeed without confirming that it did. Every business effect is built to survive that.
The same event arrives twice
Events are treated as at-least-once. A duplicate is detected and its business effect applied once.
A provider call times out
Nothing distinguishes a request that never arrived from one that arrived but was not acknowledged. The outcome is recorded as unknown and a reconciliation record is opened, never a false success or a blind retry.
A worker crashes mid-operation
Work is claimed durably in the database. In the crash scenarios that have been exercised, an interrupted operation is picked up again from that record. Attempts that are durably recorded count toward a retry budget; an attempt that cannot record itself does not. Some combinations of failures are not recovered automatically; they are documented limits, not guarantees.
The queue loses its state
PostgreSQL, not the queue, holds the business record. If the queue loses its state, work that was published but is not yet resolved is re-driven from the database within its remaining retry budget. Some combinations of failures are not recovered automatically; they are documented limits, not guarantees.
Each scenario above has been exercised in automated tests, including injected infrastructure failures and process crashes, against disposable PostgreSQL and Redis. No real provider, POS, or production infrastructure was involved.
Security and tenancy
Every tenant boundary is enforced on the server.
OneAggrgtr is multi-tenant by design, with an organization, business, and location hierarchy that access control follows all the way down.
Tenant-scoped roles
Permissions are checked server-side on every request against the caller's current role grants, never trusted from the request.
Encrypted credentials
Provider credentials are encrypted at rest and are never returned in API responses or written to logs.
Audited operator access
Platform operators reach tenant data only through explicit, time-boxed access that leaves an audit trail.
Questions
Direct answers to the obvious ones.
No. Provider integrations are planned. The architecture is exercised against simulated providers, and live connections require provider access that is not yet in place.
No. It sits between systems. A full POS replacement is outside its scope, as are loyalty, ERP, and warehouse management.
No. Payment activity that happened in another system is recorded as a reference. OneAggrgtr is not a payment processor.
Dolphin POS is designed as the first integration partner, but its integration capabilities have not been confirmed. The model is meant to let other POS systems connect the same way later.
The outcome is recorded as unknown, not guessed. A reconciliation record is opened so the result can be confirmed and resolved deliberately, without anyone editing database rows.
Not yet. A Developer Portal and Sandbox are planned; nothing is published today.
Want to see how this fits your systems?
Tell us what you run and what you need to connect. We will be plain about what exists today and what would have to be built or arranged.