Authentication

API keys

Create and manage keys in the dashboard under Keys. Each key is scoped to a plan tier (Free, Pro, or Enterprise) and a monthly quota. A key can also be restricted to specific token configurations, so an integration only touches the assets it should.

Making authenticated requests

Send the key in the Authorization header using the Bearer scheme. All traffic must use HTTPS.

curl https://passify.biz/api/v1/kyc/status/7xKXtg2... \
  -H "Authorization: Bearer passify_live_xxx"

A missing or invalid key returns 401:

{
  "error": "unauthorized",
  "detail": "Missing or invalid API key.",
  "request_id": "a1b2c3d4"
}

Test mode

Create a test-mode key in the dashboard (choose Test when creating a key) to build your integration in a deterministic sandbox. Test keys carry the passify_test_prefix and behave exactly like live keys at the HTTP level — same endpoints, same response shapes — but every response is synthesized deterministically from your inputs. No KYC provider is contacted, no transaction touches mainnet, and no real attestation data is read or written.

curl https://passify.biz/api/v1/kyc/status/7xKXtg2... \
  -H "Authorization: Bearer passify_test_xxx"

{
  "status": "verified",
  "attestation_id": "att_test_9f2ak3xq",
  "schema": "kyc_individual_v1",
  "expires_at": "2099-01-01T00:00:00.000Z",
  "test": true
}

• Every test-mode response includes "test": true.
• The same input always returns the same output, so assertions are stable in CI.
• A test-mode wallet always reads as verified, so you can exercise the full verify → mint/transfer flow without running a KYC session.

Key prefixes & identification

Keys follow the pattern passify_live_…. The dashboard displays only the first characters (for example passify_live_xK2m••••) so you can identify a key without exposing it. The prefix is safe to log; the full key is not.

Rotation & revocation

Rotate keys on a schedule and immediately whenever one may have leaked. Because each integration uses its own key, you can revoke a single compromised key without disrupting the others.

1. Create a new key in the dashboard.
2. Deploy it to the affected integration.
3. Confirm traffic has moved to the new key (check last used in the dashboard).
4. Revoke the old key.

Best practices

• Store keys in a secret manager or environment variables — never in source control or client code.
• Use a distinct key per environment (development, staging, production) and per integration.
• Scope keys to only the token configurations they need.
• Watch usage against your monthly quota; exceeding it returns 429.