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.
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.
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.
Cancelling an order does not by itself cancel it at a marketplace or delivery provider. Cancelling at a provider is a separate request, possible only where that provider's connection supports it and the capability has been verified. Anything that may already have reached a provider is tracked in the reconciliation record above.
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 what that provider's connection has been verified to support.
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.
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.
Not in production. The Uber Eats and Uber Direct adapters have been tested in Uber's test environments, and every other provider role is exercised against simulated providers. Production connections need credentials, certification, and access that are 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.
The interactive walkthrough on the How it works page shows the order flow in simulation. POS partners can try the partner API on a hosted sandbox by invitation; its orders are simulated, and no provider is connected to it. Contact us to ask about access.
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.