API keys
Create restricted test and live keys for ATM developer utilities without weakening XRPC service-auth.
Compatible with the closed-beta ATM app APIs and versioned ATM event headers. Check atm-api-version on every webhook or XRPC receiver event.
Credential boundary
ATM API keys are long-lived server credentials for a deliberately small set of developer utility routes. They never authorize /xrpc/*. Protocol, checkout, catalog, ticket, and money calls continue to require short-lived app service-auth JWTs bound to the caller DID, audience, and exact lxm.
Environments and permissions
Every key is bound to one app DID and exactly one environment. Test keys begin with atm_sk_test_; live keys begin with atm_sk_live_. ATM verifies the stored binding in addition to the visible prefix.
For diagnostics, the current full grammar is atm_sk_(test|live)_key_<24 lowercase hex>_<43 base64url>. Treat keys as opaque; never derive authority from their text.
| app.config.read | Read sanitized configuration for the key environment. |
|---|---|
| webhook.deliveries.read | List webhook and XRPC receiver delivery metadata. |
| webhook.deliveries.redrive | Redrive deliveries only in the key environment. |
| webhook.test.write | Send synthetic test events; unavailable on live keys. |
Permissions and IP rules are immutable. Create a replacement key when its authority needs to change; do not share one key across unrelated servers or jobs.
Create and use a key
Open Developer settings, choose Test or Live, then open API keys. Name the key for one deploy target and select only the permissions it needs. New keys start with read-only permissions; redrive and test-event authority are explicit opt-ins. ATM reveals a key with 256 bits of secret material once and stores only its SHA-256 digest.
curl \
"https://checkout.atmosphere.money/api/app/developer/config?environment=test" \
-H "Authorization: Bearer $ATM_TEST_API_KEY"- Store the key in the backend or CI secret manager for the matching environment.
- Never put an API key in browser code, source control, public AT Protocol records, prompts, URLs, or client-visible errors.
- Treat app and environment query values as assertions; the verified key row is the authority.
IP restrictions
A key may allow up to 25 IPv4 or IPv6 addresses and CIDR ranges. Restricted requests fail closed when ATM cannot obtain a trusted source address or the observed address is outside the list. Use this for servers with stable egress; rotate to a new key when the network policy changes.
Rotate and revoke
Rotation creates a new one-time-reveal secret with the same name, permissions, and IP rules. The predecessor remains valid for 24 hours so you can deploy and verify the replacement, then expires. Revoke either key earlier after successful cutover. Revocation is immediate and irreversible for subsequent requests. ATM permits 10 active keys per app environment, including keys in overlap; revoke another key before rotating at that cap.
Request logs
Developer settings shows a paginated, environment-scoped history of API key calls, retained for 30 days by default: key name and id, required permission, method and route, trusted source IP, user agent, response status, duration, and authenticated denial reason. Use Load older requests to traverse the retained window. Responses include Atm-Request-Id for correlation. ATM never logs the bearer, digest, Authorization header, request body, or response body.
XRPC verification attempts remain in the separate service-auth request log because their identity and method-scoping semantics are different.