Authentication

Bearer token

All requests require a Bearer token in the Authorization header:

Authorization: Bearer mk_live_abcdef0123456789...

Keys start with mk_live_ (production prefix). Each key belongs to a single user and inherits that user's API subscription state. If the subscription lapses, the key stops working — existing keys are not deleted.

Requests without a valid Authorization header return 401 invalid_credentials. Requests with a valid key but no active subscription return 403 subscription_inactive.

Creating keys

Sign in to getmockly.com and go to Account → API keys. Click Create new key.

The full key is shown once at creation. Copy it immediately and store it somewhere safe — typically a secret manager, a .env file, or your CI secrets store. After the modal closes, only the prefix (e.g. mk_live_aB3...) is visible to identify the key in the list.

You can have multiple keys per account — useful for different environments (prod, staging, CI) or different services.

Revoking keys

Click the trash icon next to a key on the API keys page. Revocation is immediate — any in-flight request using that key fails with 401 invalid_credentials from the next request onward. There's no soft-delete or grace period.

There's no programmatic revocation endpoint in v1. If a key is leaked publicly (committed to a public repo, posted in chat), revoke it from the dashboard and mint a fresh one.

Security notes

• Server-side only. Treat keys like any other secret. Don't ship them in client code, mobile bundles, or browser-side fetches. We don't support CORS for /api/v1/* for this reason.
• Hashed at rest. Keys are stored as SHA-256 hashes. Even with database access, the plaintext key isn't recoverable. That's also why we can only show the key once.
• No IP allowlisting in v1. If you need this, email us.
• Rotation. No automated rotation; mint a new key and revoke the old one when ready.