Reference
SDKs
Paycux does not publish an SDK in any language today. The control plane is a JSON API over HTTPS, and every example on this page calls it with curl. The per-language pages in the navigation are roadmap material, not packages you can install.
No SDK today
There is no npm, PyPI, Go module, RubyGems, Composer, Maven or NuGet package for Paycux. A dependency named paycux in any registry is not ours. Integrate with the HTTP client your runtime already has.
- Every implemented route and the credential it requires is listed under What exists today, rendered verbatim from docs/API_CONTRACTS.md
- Every request and response body is JSON; validation failures return 400 with the error code INVALID_INPUT
- The control-plane host is https://api.paycux.com; the examples below call it directly
The three credentials
Paycux has no secret API keys. Each route family accepts exactly one kind of credential, and they are never mixed: a dashboard session can never satisfy an end-user route, and a realm token cannot read workspace data.
| Identity | Carried as | Routes |
|---|---|---|
| Dashboard member sessionA member of your Paycux workspace, signed in to the console | __Host-paycux_session cookie | /v1/projects, /v1/environments, /v1/workspace, /v1/auth/* |
| End-user usage credentialYour own application's user, signed in to the environment's realm | Authorization: Bearer <realm access token> | /v1/usage/events, /v1/billing/* |
| Agent connectionA CLI or coding agent bound to one project's development environment | Authorization: Bearer <short-lived agent token> | /v1/agent/*, /v1/verifications/* |
Dashboard session
The console signs you in with OpenID Connect and stores the result in a host-bound, HttpOnly cookie. That cookie is the credential for workspace routes: projects, environments, members, catalog and workspace billing. It belongs to the browser session; there is no API key for workspace administration today.
1curl https://api.paycux.com/v1/auth/session \2 -H "Cookie: __Host-paycux_session=<value from your signed-in browser>"34# 2005{ "workspaceId": "…", "actorId": "…", "role": "owner" }
Session mutations check the Origin header
Refresh, logout, workspace switch and every workspace billing mutation require the exact console origin in the Origin header and answer 403 otherwise.
Realm access token
Your application's users authenticate against the identity realm Paycux provisions for each environment. Send that realm's access token as a bearer token. Paycux verifies it against the realm's published keys and audience, requires a verified e-mail and maps the subject to a realm-scoped identity, created on first use.
1curl -X POST https://api.paycux.com/v1/usage/events \2 -H "Authorization: Bearer $REALM_ACCESS_TOKEN" \3 -H "Idempotency-Key: usage-2026-10-13-000001" \4 -H "Content-Type: application/json" \5 -d '{6 "projectId": "<project uuid>",7 "environmentId": "<environment uuid>",8 "realmId": "<realm uuid>",9 "billingAccountId": "<billing account uuid>",10 "meterKey": "api_calls",11 "quantity": 1,12 "occurredAt": "2026-10-13T09:00:00Z"13 }'1415# 200 UsageDecision16{17 "allowed": true,18 "reason": "WITHIN_LIMIT",19 "consumed": 1,20 "limit": 1000,21 "eventId": "…",22 "duplicate": false23}
- The body scope (projectId, environmentId, realmId) must match the credential, and the identity must be an active member of the billing account
- Idempotency-Key is 8 to 128 characters; repeating a key returns the same decision with duplicate: true
- Checkout, portal and cancellation sessions use the same credential under /v1/billing and are created on your own Stripe or Paddle account
Agent token
An agent connection binds a CLI or coding agent to one project's development environment. The token is short-lived, starts with pcx_ and carries only the capabilities it was issued with: read the integration contract, start a verification run, read a verification run. The paycux CLI and the paycux-mcp server read it from a protected pipe, never from a flag or a file.
1curl https://api.paycux.com/v1/agent/contract \2 -H "Authorization: Bearer $PAYCUX_AGENT_TOKEN"34# 200 — the project's public integration contract; no provider secrets
Conventions
Four rules hold across every implemented route.
JSON in, JSON out
Request bodies are JSON objects with camelCase keys and UUID identifiers. Responses are JSON; 204 means no body.
Errors carry a code
Failures return { error, message } with codes such as INVALID_INPUT, CREDENTIAL_INVALID, FORBIDDEN, NOT_FOUND, CONFLICT, PLAN_LIMIT_EXCEEDED and RATE_LIMITED, the last with a Retry-After header.
Writes that touch money are idempotent
Usage events, hosted checkout and workspace billing writes take an Idempotency-Key. Retrying is safe; changing the payload under the same key is a 409.
Secrets never come back
Provider API keys and webhook secrets are stored by reference and are never returned, logged or echoed in an error.