DocumentationAPI key security

API key security

Rotation, environment separation, and no client exposure.

API keys grant programmatic access to your tenant. Treat them like passwords with scoped permissions.

Never expose keys in the client

EnvironmentRule
Productionmc_live_ keys only on servers (env vars, secret manager)
Browser / mobileDo not embed live keys in frontend bundles
Developmentmc_test_ keys still belong on the server when possible

If you must send from the browser, proxy through your backend (Route Handler, Server Action, BFF). The MailingCore SDK in the browser is acceptable only for tightly scoped test keys and accepted risk.

Principle of least privilege

Create separate keys per service with only required scopes:

  • Transactional sender → email:send
  • CRM sync → contacts:read, contacts:write
  • Webhook admin → webhooks:manage

See API keys and scopes.

Rotation procedure

  1. Create a new key with the same scopes (dashboard or POST /tenants/:id/api-keys).
  2. Deploy the new secret to all environments (blue/green or rolling).
  3. Verify traffic (test send, health check).
  4. Revoke the old key: DELETE /tenants/:id/api-keys/:keyId.

Overlap both keys briefly during rotation to avoid downtime.

Storage

  • Use your platform secret store (Vercel, AWS Secrets Manager, Vault).
  • Restrict dashboard access to team members who need it; enable 2FA for admins.
  • Keys are stored as SHA-256 hashes — plaintext cannot be recovered after creation.

Incident response

If a key leaks:

  1. Revoke immediately in the dashboard.
  2. Create a replacement with minimal scopes.
  3. Review audit log and recent GET /emails/logs for abuse.
  4. Rotate related secrets (webhook endpoint secrets if compromised).

Related