Developers
Guides for authentication, wallets, rewards, tokens, events and AI.
Overview
The guides are arranged by task — issue a reward, verify a webhook, freeze a wallet — rather than by the internal service boundaries behind them. You should never need to know which of the fourteen internal services owns a table to find the page you need.
Each guide covers the same four things: the concepts, the calls involved, the failure modes, and what changes when you move from sandbox to production.
What follows is the map: each area below states what its guide covers and the behaviour the specification pins down.
The guides
Sessions for people, API keys for systems. A key is scoped to one organization and one environment, its secret is returned once at creation, and revocation keeps the key resolvable in request logs rather than deleting it.
Teams, roles and resource.verb permission codes. X-Organization-ID is client-supplied and therefore never trusted: it is validated against the authenticated principal on every request.
Customer records keyed by your external id — a second create with the same id is customer_external_id_taken, not a duplicate. Segments are derived from what a customer holds and does; read them, do not try to write them.
Every balance is the sum of double-entry ledger entries; balances are served from a snapshot cache over them. Posted transactions are immutable — corrections are reversals, never edits. Wallets can be frozen, and policies cap what a transfer may move.
An asset moves through a lifecycle — created, validated, active — and can be paused as an emergency control. Supply ceilings are enforced at issuance. Blockchain deployment is optional, separate and explicitly confirmed; until then an asset lives entirely on internal infrastructure.
Programmes are versioned: edits go to a draft, publishing makes the version immutable, and rules pair conditions with actions. Events deduplicate on your external event id, can be replayed safely, and are the only input the reward engine needs.
Signed outbound delivery. The signing secret is returned once at registration; verify with a constant-time comparison. Failed deliveries retry on a fixed schedule — immediate, 1m, 5m, 30m, 2h, 8h, 24h — so handlers must be idempotent.
A proposal-and-approval boundary: an agent can propose actions but approval is the only path to execution, and an agent can never hold a permission its creator lacks. Context is permission-checked before a model sees any business data, and cost limits stop a run rather than degrading it silently.
Published workflow versions are immutable and historical executions retain the exact version they ran. Definitions are validated before publication — including that every loop has a bound — and a replay is a new linked execution, never a mutation of the original.
Analytics are served from daily aggregates, never from transactional tables. The audit trail is append-only and read-only at the API — there is no write endpoint to misuse. Sensitive exports run as background jobs and generate audit events.
Structure
Every guide follows the same eight-part structure, so a reader always knows where to look.
What the page covers and who it is for.
Accounts, credentials and versions needed first.
Getting the dependency in place.
Working code for the common path.
What to do and what to avoid in production.
The surface this page depends on.
Failure modes and how to recover.
Full parameter and response detail.
Reference
Access is reviewed. Tell us what you are building and we will let you know when the developer documentation opens.