API Keys

Every API call uses an API key. Each key belongs to one mode (test or live) and cannot be switched after creation. The mode is controlled by the Test mode switch at the bottom of the sidebar, not a form field.

A full key is 72 characters: the 8-character prefix plus 64 hex characters of random data. Keys are shown only once at creation, after which only the 16-character key prefix is visible.

Do not expose API keys in browser code, mobile apps, or public repositories. Store them server-side.

Create a key

You need at least one active wallet in the current mode before you can create a key. The API Keys page shows an empty state directing you to add a wallet first.

A key is active immediately. You can have multiple keys per mode and revoke each one independently.

Allowlists

The API key allowlist is the enforcement boundary for which coins you receive. The create form treats your wallets' chain and token coverage as the default allowlist. Restrict per key if you run partner integrations or want a key scoped to a single coin.

• Accepted chains. The chains this key can create payments on. The picker auto-selects every chain you have a wallet for. Deselect to block.
• Accepted tokens. The coin variants (e.g. USDT-TRC20, USDT-ERC20, USDC-SPL are independent pairs). Auto-selects every token on the accepted chains. The create form presents both as one combined Accepted payment methods picker.

A hosted checkout only ever offers coins inside this allowlist, and a checkout with no coin left inside it is rejected at creation. This is different from the per-request accepted_chains / accepted_coins / accepted_tokens fields, which by default only pick the checkout default coin and never widen or restrict what the key allows: a request that names a coin outside the allowlist is simply ignored (no default), not rejected. To make a single request's accepted set a hard restriction (a subset of the key allowlist) without minting a per-group key, send restrict_to_accepted: true on that create-payment call. The checkout then offers only that subset.

Webhooks per key

Each key has its own webhook endpoint and signing secret. A key without a webhook still creates payments. It just sends no notifications.

Add a webhook

Use Send test on the webhook panel to fire a synthetic event and verify your endpoint is reachable.

Rotate the signing secret

Click Rotate secret on the webhook panel. The new secret is shown once in the dialog. After rotation there is a 24-hour grace window where deliveries are signed with both the new and the old secret (the X-Webhook-Signature header carries multiple v1= values), so update your verifier within 24 hours. After the window the old secret stops verifying.

See Webhooks for the full signature-verification flow.

Revoke a key

Click Revoke... on the key's row. The confirmation dialog reads Revoke "<label>"? with the action button Revoke key.

Revoked keys return 401 Unauthorized on every request immediately. There is no undo. Create a new key if you revoke one by mistake.

Rate limits

API endpoints authenticated by an API key are rate-limited to 2 requests per second per client IP with a burst of 10. Exceeding the limit returns 429 Too Many Requests. Use exponential backoff in your integration.

A few endpoints have tighter buckets (auth flows, invoice send/resend, public checkout SSE). See the response body and Retry-After if you hit one.

Test vs live

• Test keys create payments on testnet chains only. Live keys create payments on mainnet chains only. The platform enforces this via the chain's is_testnet flag on every POST /api/v1/payments.
• Test and live Prepaid Credit reserves are separate. Both modes deduct fees from their own reserve. New accounts are auto-credited $100 test and $50 live at signup.
• Switch your integration from test to live by replacing the test key with a live key in your configuration. The API calls are otherwise identical.