Overview

WAMP’s identity system answers four different questions, and each one has its own credential. This page tells you which one you need and where the instructions are. It also tells you the two things about WAMP identity that surprise people: there is no self-service sign-up, and there is no single base URL.

Pick a credential

Your job	Credential	What it proves	Page
A human signs into your app with their WAMP account	OIDC access token and ID token, from authorization code + PKCE	This person is this WAMP user, in this organization	Sign in with WAMP
Your backend calls WAMP on behalf of a signed-in user	The same OIDC access token, forwarded	The user consented to your client	Sign in with WAMP
Your backend calls WAMP as itself, for one customer organization	App installation access token, obtained by exchanging an app assertion	Your app, installed in that organization, holding those capabilities	Apps and credentials
Your own server-side job needs the AI proxy, no app involved	Organization API key (wamp_sk_…)	Some member of that organization created this key	Apps and credentials
Your product has its own users and you want WAMP to hold them	End-user AI token, minted by WAMP or signed by you	This end user of yours, billed to your installation	Hosted end-user accounts

Two of those are not interchangeable in a way that catches people out. An OIDC access token identifies a human; an app installation token identifies your software acting inside a customer’s organization. There is no OAuth client_credentials grant on this platform, so machine-to-machine access always goes through the app assertion exchange rather than a client secret.

Account creation, honestly

There is no self-service sign-up. POST /auth/register exists and always answers 403 {"success": false, "error": "Registration is currently closed"}. Nothing else creates a platform account.

The only path onto the platform is accepting an organization invitation. Someone who already holds organization.members.invite in an organization invites an email address; the invite link carries a single-use token in the URL fragment; opening it in Account Center lets the recipient set a name and password and become a member in one transaction. Registration is driven by Account Center itself — the underlying endpoint enforces same-origin against the Account Center host, so it is not something you can drive with curl.

So when you plan onboarding for your integration, plan it as “get invited to an organization”, not “sign up and create an org”. Organizations themselves are created through an operator bootstrap path, not by signed-in users.

One more thing to design around: email_verified is always false. The claim is released under the email scope, but no email-verification flow exists anywhere in the platform. If you are a relying party, do not gate anything on that claim, and do not treat a WAMP email address as proven.

Things developers expect that are not here

Expected	Reality
Client secrets	None exist. A client is either public (none) or authenticates with private_key_jwt signed by your own Ed25519 key.
client_credentials grant	Disabled. Use the app assertion exchange.
Device authorization flow	Disabled.
Dynamic client registration (RFC 7591)	Disabled twice over — the feature is off and the storage adapter refuses. You create clients through the app API instead.
Token introspection (RFC 7662)	Disabled. Verify JWTs locally against the JWKS.
RS256 / HS256 tokens	Every token this platform signs is EdDSA (Ed25519).

Before your first call

There is no single base URL. WAMP’s backend is two independently deployable processes with disjoint route tables, and a path exists only on the process that mounts it:

• The Account process serves identity: /oauth2/*, /auth/*, /api/apps/*, /api/organizations/*, /api/invitations/*, /a/:slug/*, and the AI proxy WebSocket at /ws.
• The Cloud process serves the WAMP Cloud product plane: /v1/*, /cloud/sessions/*, git transport, and GitHub integration. It authenticates differently and is documented on its own site: docs.cloud.vampikez.fun.

A deployment may put both behind one hostname on different path prefixes. That means GET /.well-known/jwks.json can resolve to two different key sets depending on which process answers — the Account platform keys, or the Cloud runner keys. Never assume one JWKS URL covers everything; take the OIDC JWKS URI from the discovery document, as described in Sign in with WAMP.

Throughout these pages, two values are yours to fill in, and neither can be guessed from a client:

Placeholder	What it is	How you get it
$API	The Account API origin, e.g. https://api.example.com	From the operator of the deployment you integrate with
$ISSUER	The OIDC issuer, e.g. https://account.example.com/oauth2. Always ends in /oauth2	From the operator; everything else is discovered from it

Error bodies are not uniform, and you have to code for all three shapes. They differ by which layer rejected you:

Layer	Body	Example
Authentication middleware	{"error": "<prose>"}	{"error": "Invalid or expired token"}
Account route handlers	{"success": false, "error": "<machine_code>"}	{"success": false, "error": "app_not_found"}
Cloud plane	{"error": "<machine_code>"}, no success field	{"error": "cloud_access_denied"}

Machine codes are stable and worth branching on. The prose strings are not — treat any 4xx from the middleware layer as “re-authenticate”.

Where to go next

• Sign in with WAMP — the complete authorization code + PKCE flow, claim validation, refresh, logout, and the failures that cost the most time.
• Organizations and roles — accounts, memberships, invitations, the 14 organization permissions, and how product access is granted.
• Apps and credentials — every credential a third-party developer can hold, with header format, lifetime, and revocation.
• Hosted end-user accounts — letting WAMP hold your product’s user directory.