Overview

Choose credentials by the API receiving them. OIDC sign-in, platform management, app installations, end-user model access, and connected resources have distinct issuers or audiences; they are not interchangeable.

What you need before any code

Configure these values for the deployment before issuing or verifying tokens.

Value	What it is	How to get it
$API	The Account API origin. Every /auth/* and /api/* call on these pages is relative to it	On this deployment it is https://api.vampikez.fun; on another, ask for its Account origin
$ISSUER	The OIDC issuer. It always ends in /oauth2	On this deployment it is https://account.vampikez.fun/oauth2; every OIDC endpoint is then discovered from $ISSUER/.well-known/openid-configuration
$TOKEN_ISSUER	The issuer of platform-signed non-OIDC tokens and the required aud of an app assertion	https://api.vampikez.fun on this deployment; confirm the configured JWT_ISSUER with its operator elsewhere. Never derive a verifier’s trusted issuer from an unverified token
App slug and public key	Your app’s identity in a publisher organization, and the Ed25519 public key its assertions are signed against	You pick the slug when you create the app, then register the key; both need organization.applications.manage in that organization — see Apps and credentials

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 protects its own API for a signed-in user	Your client’s OIDC access token	The user consented to that client and organization; this token does not authorize WAMP platform APIs	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 remote MCP service receives the current WAMP principal	Connected-resource identity JWT	Exact resource App, installation, tenant, subject, audience, and origin	Connected resources

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 new machine-to-machine access goes through the app assertion exchange rather than a client secret.

Account creation, honestly

There is no self-service sign-up. New users enter through organization invitations; no public registration route exists.

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 metered AI proxy as HTTP: GET /v1/models, POST /v1/responses, POST /v1/chat/completions. It has no WebSocket upgrade plane; GET /ws is 404.
• The Cloud process serves the WAMP Cloud product plane: the rest of /v1/*, /ws/cloud/sessions/*, /cloud/sessions/*, git transport, and GitHub integration. It authenticates differently and is documented on its own site: docs.cloud.vampikez.fun.

Use the Account platform JWKS at $API/.well-known/jwks.json for the platform token contracts documented here. For OIDC, take jwks_uri from the trusted issuer’s discovery document. Cloud does not publish a runner JWKS at that route; its runner machine protocol is separate from app credentials.

$API and $ISSUER appear throughout these pages as the placeholders described in What you need before any code.

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 — re-authenticate for an expired or invalid credential (401); handle permission refusal (403), validation failures, and rate limits separately. Repeating sign-in does not grant missing authority.

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.