Developers
Integrate in an afternoon, not a quarter
Standard protocols, predictable errors, and documentation that admits what is not finished.
Quickstart
Create an application, copy the client id, point your OIDC library at the discovery document and handle the callback. If you have integrated an identity provider before, there is nothing surprising here.
Intents beyond sign-in
Create a login intent or an action intent, bind it to the exact values that must be approved, then poll or take a webhook. The approval you receive is cryptographically tied to what the person was shown.
Errors that tell you what to do
Consistent JSON error shapes with a stable code, a human-readable message and a request id. Failures during a ceremony deliberately do not tell you which check failed — that would be a debugging aid for forging one — but everything else is specific.
Rate limits and idempotency
Documented limits with Retry-After on rejection, and idempotency keys on anything that creates a billable event, so a retried request does not become a second charge.
Credentials handled properly
Secrets are shown once, stored as digests, rotatable and revocable. Sandbox and production keys are separate records with a hard environment discriminator, so the classic accident of shipping a test key to production fails closed.
What is not ready yet
The OAuth and OIDC endpoints, the versioned REST API, webhooks and the SDKs are in active development. This page describes the design they are being built to; the developer area marks each piece as live or in progress. Nothing is documented here as working when it is not.
Open a free sandbox
Start building against the parts that are live today.