A key belongs to one project and one of its environments (production or preview):

Property Values
Mode live sends real mail; test delivers nothing (Test mode) and sees only test-mode mail and events.
Scope full_access, sending_access or inbound_read, see Scopes.
Domain Optional, for sending_access keys only (422 validation_error on any other scope). A restricted key sends only from that domain of the project, and reschedules and cancels only mail from it (other mail is 404 not_found).
Rate limit Requests per second, 10 by default, never above the project's key rate ceiling (10 unless raised in Settings, at most 100).

The key itself, minket_live_… or minket_test_…, is shown once, when it is created. Only its SHA-256 hash is stored; afterwards the console and the API show display, the prefix, the mode and the last four characters, such as minket_live_…k9Qz. Its last use is recorded to the minute.

Scopes

Scope Allows
full_access Every route of the project.
sending_access Sending (single and batch), rescheduling and cancelling, and uploading attachments. It cannot read mail, templates or suppressions, but it can send with a template it cannot read.
inbound_read Received messages and their attachments. It cannot change routing or forward mail.

Every scope may call GET /v1/keys/current. A key used outside its scope gets 401 restricted_api_key.

Test keys never change what live mail shares. They cannot manage keys, read members, change domains, mailboxes or inbound routes, or change the audience (contacts, contact properties, segments and their members, topics, consent), automations or templates: 403 test_mode_only. They can read domains, mailboxes, inbound routes, the audience, automations and templates, preview templates, export contacts and send custom contact events, which start test-mode runs only.

Create a key

In the console, open Keys and choose Create key: a name, the environment, live or test, the scope, and optionally a domain and a rate limit. The setup flow's Keys step creates a live and a test key for production at once, with the settings to paste.

With the API, a live full-access key creates keys for its own environment:

curl
curl https://api.minket.com/v1/keys \
  -H "Authorization: Bearer $MINKET_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "backend",
    "environment_id": "019a2b3c-4d5e-7f60-8a9b-0c1d2e3f4a5b",
    "mode": "live",
    "scope": "sending_access"
  }'
JSON
{
  "id": "019a2b3c-4d5e-7f60-8a9b-0c1d2e3f4a60",
  "object": "key",
  "project_id": "019a2b3c-4d5e-7f60-8a9b-0c1d2e3f4a50",
  "environment_id": "019a2b3c-4d5e-7f60-8a9b-0c1d2e3f4a5b",
  "name": "backend",
  "mode": "live",
  "scope": "sending_access",
  "domain_id": null,
  "rate_limit_per_second": 10,
  "display": "minket_live_…k9Qz",
  "token": "minket_live_…",
  "last_used_at": null,
  "created_at": "2026-10-24T18:00:00.000Z",
  "revoked_at": null
}

token is in this response only. A key made with another key may be live or test, but never broader than the key that made it:

  • it stays in that key's environment (another environment_id is 401 restricted_api_key);
  • a domain-restricted key makes keys restricted to the same domain, which they inherit when domain_id is left out;
  • rate_limit_per_second stays within the creating key's and the project's ceiling (422 invalid_parameter).

An environment_id or domain_id from another project is 404 not_found.

List, check and revoke

curl
# Active keys of this key's environment, newest first.
curl "https://api.minket.com/v1/keys?limit=20" -H "Authorization: Bearer $MINKET_API_KEY"

# The calling key: project, environment, mode and scope.
curl https://api.minket.com/v1/keys/current -H "Authorization: Bearer $MINKET_API_KEY"

# Revoke: the key is refused from its next request.
curl -X DELETE https://api.minket.com/v1/keys/019a2b3c-4d5e-7f60-8a9b-0c1d2e3f4a60 \
  -H "Authorization: Bearer $MINKET_API_KEY"

Lists never carry the key or its hash. Revoking a key that is already revoked, or one of another environment, is 404 not_found. Every creation and revocation is in the organization's audit log with the key's name, mode and scope, never the key.

Updated