Developer API Docs

Use FateID pass endpoints with your Developer API key

This key is designed for read-only integrations that need protected access to FateID pass data. It is currently limited to documented pass endpoints and is available to Pearl Pass accounts or staff-approved overrides.

Back to API Keys View Membership

Access level

Read-only

Primary auth

Bearer key

Plan gate

Pearl Pass+

Current Endpoint Access

Documented routes

These are the routes your current Developer API key model is allowed to call.

GET

/api/pass/:passUid

Fetches the public FateID pass payload for a valid pass UID.

Requires a Developer API key in the Authorization header or x-api-key header.
Read-only endpoint. It does not modify user or pass data.
The pass UID must start with pass_.

GET

/api/pass/:passUid/json

Fetches the same pass payload as formatted JSON text.

Useful when your integration expects explicit JSON content output.
Requires the same Developer API key authentication as the standard pass endpoint.
Read-only endpoint. It does not modify user or pass data.

GET

/api/subscriptions/plans

Fetches the available subscription pass catalog, including pass names, levels, prices, limits, and benefits.

Requires a Developer API key in the Authorization header or x-api-key header.
Returns the current public tier catalog such as Basic Pass, Silver Pass, Gold Pass, Pearl Pass, Diamond Pass, and VIP Pass.
VIP rows include supportLevelOptions for supported VIP support amounts.

Capabilities

What the key can do

Authenticate requests to protected FateID pass endpoints.
Read pass data for valid public pass UIDs.
Read the available subscription pass catalog for integrations that need tier metadata.
Be revoked immediately by the account owner or staff.

Guardrails

What the key cannot do

No admin route access.
No profile, account, payment, or membership write access.
No replacement for the normal dashboard login session.
No wildcard access to future endpoints unless they are explicitly documented.

Tutorial

How to use your Developer API key

The normal flow is create a key in the dashboard, store it in your server environment, then send it in request headers.

Create the key once

Open Dashboard API Keys, create a Developer API key, and copy the raw secret immediately.

Store it outside source control

Save the key in a server-side environment variable or secret manager, not in frontend code or checked-in config.

Send it with each request

Use the Authorization: Bearer <key> header. The x-api-key header is also supported.

Handle error responses

Treat non-2xx responses as actionable integration signals. Inspect the status code, verify the pass UID, and confirm the key is still active.

Examples

Request samples

cURL

curl \
  -H "Authorization: Bearer YOUR_DEVELOPER_API_KEY" \
  https://fateid.com/api/subscriptions/plans

JavaScript fetch

const response = await fetch('https://fateid.com/api/subscriptions/plans', {
  headers: {
    Authorization: 'Bearer YOUR_DEVELOPER_API_KEY'
  }
})

if (!response.ok) {
  throw new Error('Request failed: ' + response.status)
}

const payload = await response.json()
console.log(payload.tiers)

Python requests

import requests

response = requests.get(
    'https://fateid.com/api/subscriptions/plans',
    headers={'Authorization': 'Bearer YOUR_DEVELOPER_API_KEY'},
    timeout=15,
)
response.raise_for_status()
print(response.json()['tiers'])

Lifecycle

Key issuance and revocation

Only Pearl Pass and higher can issue Developer API keys unless staff grants an override.
A raw key is shown only once when created.
Only hashed key records are stored on the server.
Revoked keys stop working immediately.

Security

Recommended practices

Keep keys server-side whenever possible. Do not hardcode them into public frontend bundles.
Use the Authorization: Bearer <key> header for normal server-to-server requests.
Rotate keys if you think a secret was exposed.
Use separate keys for separate environments or integrations so revocation is clean.
Treat 401 or 403 responses as a signal to inspect key status, plan access, and staff overrides.

Errors

Common API responses

Status	Meaning
`400`	The request is malformed, such as a missing or invalid pass UID.
`401`	The Developer API key is missing, invalid, revoked, or not active.
`403`	The account is not allowed to use Developer API keys for that request.
`404`	The requested pass UID does not exist.
`500`	Server-side configuration is incomplete or an internal error occurred.