Skip to content
OneAggrgtr

Developer roadmap

One integration surface, instead of one per provider.

OneAggrgtr owns the connections to marketplaces and delivery providers. A POS partner is designed to connect once, to OneAggrgtr, rather than integrating each provider separately.

Public API
Not available
Sandbox
Not available
API keys
None issued
What has been demonstrated
Simulated end-to-end flows
Not available yet

There is no public API, no API keys, and no sandbox today. The integration contract is still being designed, and it will follow what integration partners can confirm they are able to do. Nothing on this page describes a published endpoint.

Ask about the integration model

Integration direction

Partners connect in. OneAggrgtr connects out.

The direction is deliberate. It keeps every partner-specific model at the edge and every provider-specific model behind an adapter, with one canonical model between them.

  1. POS partner

    Connects to OneAggrgtr, not the reverse

  2. Integration API

    Contract in design, not published

  3. Canonical model

    Partner data normalized once

  4. Provider adapters

    OneAggrgtr owns these connections

  5. Marketplaces and delivery

    Planned, not yet connected

The same surface is intended to serve future POS partners, not only the first. Whether a given partner can connect this way depends on what that partner confirms it can do.

Design principles

What the integration surface is built around.

These principles govern how OneAggrgtr is built today. They are commitments about behavior, not a published contract.

At-least-once by default

Events may arrive twice, late, or out of order. Operations are designed to be idempotent, so a retry is always safe.

Capabilities are explicit

Each capability is tracked as verified, presumed, unknown, or confirmed absent. Unknown is treated as absent until verified.

Your identifiers stay yours

External IDs are stored as mappings to canonical records. They are references, never OneAggrgtr's identity for anything.

Failures are recoverable

An outcome that cannot be confirmed is surfaced as unknown and reconciled, not hidden and not guessed.

Planned

A Developer Portal and Sandbox.

Both are planned as first-class product surfaces. Neither exists yet, and no date is committed.

  • Integration documentation

    Planned

    Setup and configuration guidance for connecting.

  • API reference

    Planned

    Authentication, webhooks, events, and the error model.

  • Idempotency guidance

    Planned

    How to identify and safely retry operations.

  • Provider integration status

    Planned

    Which providers OneAggrgtr supports, with capability status shown honestly.

  • Certification workflow

    Planned

    Requirements and a test path for partners.

  • Sandbox

    Planned

    Deterministic test scenarios with sandbox credentials kept separate from production.

Building a POS or platform integration?

If you would connect to OneAggrgtr, we would like to hear how your system integrates with others. That is what the integration contract will be designed around.

Get in touchEcosystem status