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
| Environment | Rule |
|---|---|
| Production | mc_live_ keys only on servers (env vars, secret manager) |
| Browser / mobile | Do not embed live keys in frontend bundles |
| Development | mc_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
- Create a new key with the same scopes (dashboard or
POST /tenants/:id/api-keys). - Deploy the new secret to all environments (blue/green or rolling).
- Verify traffic (test send, health check).
- 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:
- Revoke immediately in the dashboard.
- Create a replacement with minimal scopes.
- Review audit log and recent
GET /emails/logsfor abuse. - Rotate related secrets (webhook endpoint secrets if compromised).
Related
- Authentication
- Multi-tenant — always send
X-Tenant-Id