If a credential leaks
Stop access with the exposed secret, restore your application and review what happened.
Treat a credential as exposed if it appears in a public repository, browser code, shared screenshot, log, chat or any place where someone who shouldn't have it could copy it. Follow these steps even if you haven't seen unexpected sending.
Deleting the visible secret doesn't invalidate copies someone may already have. Revoke the credential rather than waiting for its expiry or for a replacement deployment.
1. Revoke the exposed credential
- Select the workspace where the credential was created.
- Open Credentials, titled API Keys.
- Find the key by Name and Identifier. The identifier is a prefix of the key.
- Click Revoke, check the name in the confirmation, and confirm Revoke credential.
The credential moves to Revoked. Revocation cannot be undone, and the credential cannot be rotated afterward. Applications using it will need a replacement.
If Revoke is unavailable, contact your workspace owner or administrator immediately. The action requires the corresponding credential permission.
For API keys, changes are synchronized when the API integration is configured and can take time to propagate. Confirm that the affected endpoint rejects the old key using key verification, without submitting an email. If it still accepts the key, ask your administrator to check synchronization.
Your API key is also your SMTP password, so revoking it stops SMTP sending with it too. Messages sent over SMTP are checked against the key when they are submitted, so the same verification applies.
2. Remove the source of exposure
Remove the secret from the place where it leaked and fix the path that exposed it. Revocation remains necessary even after removal.
| Where it appeared | What to check |
|---|---|
| Source control | Remove the secret from current files and address repository history, forks and build artifacts with your team. |
| Logs or error reports | Redact stored copies where possible and stop logging authorization headers, SMTP passwords or full configuration. |
| Browser code or app bundles | Move authentication to your backend. A shipped secret can be extracted even if it isn't displayed on screen. |
| Screenshots, chat or shared files | Remove accessible copies where possible and review who received them. |
| Server or CI configuration | Review access to the system that held the secret before storing its replacement there. |
If other secrets were exposed through the same incident, review and replace those separately. Changing your dashboard password does not revoke an API key.
3. Create a replacement and update your application
- Click Create credential in the affected workspace.
- Give it a recognizable name and choose an expiry.
- Click Create and save the secret from Save this secret now in your secrets manager or server configuration.
- Update every application, deployment or job that used the revoked credential.
- Restart or redeploy instances that need to reload their configuration.
For the API, replace the complete Bearer key, including its live_ prefix. For SMTP, replace the password with the new key; the username stays sendmero.
Verify the replacement when the sending service is available, then check your application's requests. Keep the new secret out of the investigation notes and screenshots you share.
4. Review email activity
Open Activity in the affected workspace. Search a date range covering the earliest possible exposure through the time access was stopped. Check unexpected recipients, sending domains, subjects and message volume; open suspicious messages to inspect their recipients and timeline.
Save relevant Message IDs, recipient addresses, timestamps and your application's request logs. Record the time zone so your team can compare events accurately.
Activity currently has no credential filter. Use available message details and your application logs to investigate; don't assume every message in that time range used the leaked credential. No matching results alone do not prove that the secret was never used.
Revoking a credential prevents further authentication once applied. It does not recall emails or cancel messages already accepted for processing.
5. Review credential and access changes
Open Settings → Audit Log. Choose credential under All resource types and review create, rotate and revoke actions around the incident. Check the recorded user and time, then review any unexpected team, role or workspace changes.
Audit Log records supported account and configuration actions; it is not a log of every API request or email. Preserve relevant entries or a filtered CSV export if you need them for your investigation.
Review and export audit entries →
If the issue continues
Contact your workspace administrator or support with the workspace, credential name and identifier, exposure and revocation times with time zones, relevant message or request IDs, and what still appears to be happening.
Do not include the full API key or SMTP password. If unexpected sending continues, establish whether it comes from messages accepted earlier, another credential, or access that hasn't yet been disabled.
- Store secrets in a secrets manager or server environment configuration.
- Use separate credentials for each application and environment.
- Keep secrets out of source control, browser code and logs.
- Limit who can access secrets and manage credentials, and review unused credentials regularly.