Developers

The identity layer, as an API.

The model

Three primitives

Everything the platform does reduces to three API ideas: resolve an identity, create a payment intent, and listen as orchestration moves it to settlement. Idempotent requests, signed webhooks, sandbox-first. Reference documentation ships with the developer program.

# Illustrative — API preview, subject to change GET /v1/identities/myqr.at%2Fmaria # resolve: who can be paid, on which rails POST /v1/payments # create: intent, not instruction { "to": "myqr.at/maria", "amount": "120.00", "currency": "EUR", "idempotency_key": "ord_8813" } # listen: signed webhooks as the flow progresses identity.resolved → rail.selected → payment.settled → payment.confirmed

Events

Webhooks

Every stage of the flow you saw animated on the homepage is an event you can subscribe to. Webhooks are signed, retried with backoff, and ordered per payment — build your ledger from the same events our reconciliation uses.

Tooling

SDK

Client libraries follow the API preview program — priority languages driven by the first partner cohort. Tell us what your stack needs when you join the waitlist.

Start here

Sandbox

The sandbox resolves test handles and routes test payments through the full event sequence — no real rails, real behaviour. The waitlist is open now.

Join the Sandbox Waitlist

Build on the identity layer

The developer program starts with the sandbox cohort. Get in early enough to shape the SDK.

Join the Waitlist