API keys

Manage the keys your applications use to send through the SendMero REST API or SMTP.

An API key belongs to the workspace where you create it. Use a separate key for each application or environment so you can replace one without changing every integration. The same key also works as the password for SMTP.

Save the full key

The secret is shown only once. Copy it before closing the dialog; the Identifier in the list is only a prefix and cannot authenticate a request.

Create an API key

1. Select the workspace your application will send from.
2. Open Credentials. The page is titled API Keys.
3. Click Create credential.
4. Enter a recognizable Name, such as Production backend or Staging app.
5. Choose an Expiry: Never expires, 6 months, or 1 year.
6. Click Create.
7. In Save this secret now, copy the complete API key into your application's secrets manager or server environment configuration.
8. Click I've saved it. Close the Send a test message dialog when you're finished.

The key appears in the list with status active. If you lose the secret, create a replacement or rotate the credential; you cannot retrieve the original value.

Use the key in your application

Send the full key, including its live_ prefix, in the authorization header:

Authorization: Bearer YOUR_API_KEY

Your server should read the key from its configuration and add this header when it calls SendMero. A browser or mobile application should call your backend, which keeps the key private.

A key authenticates the workspace; it does not replace sending-domain setup. Follow Add your sending domain before sending.

API authentication and key verification →

Check API availability

The dashboard's test-message dialog currently describes message submission as not live yet. Creating a credential does not by itself confirm that an API endpoint is ready. When the API is available for your workspace, verify the key before relying on it for production sending.

Review your keys

The list shows your API keys. Older workspaces may also show SMTP (legacy) credentials; these no longer work and can only be revoked. Use an API key as your SMTP password instead.

Field	What it tells you
Name	The application or environment you named the credential for.
Identifier	A prefix that helps distinguish API keys without exposing the full secret.
Status	Whether the credential is active or revoked. Check its expiry too.
Last used	The recorded usage time, or Never when no usage has been recorded.
Expires	The expiry date, or Never for a key without a scheduled expiry.

An active status does not extend an expired key. Plan a replacement before its expiry date. Multiple keys share the workspace's limits; creating another key does not increase your allowance.

Replace a key with a planned handover

Use a separate replacement key when you need time to update several application instances:

1. Create a new API key in the same workspace and save its secret.
2. Verify the new key using the authentication verification endpoint when available.
3. Update your application's secret configuration and restart or redeploy instances that need to reload it.
4. Confirm the application is using the replacement successfully.
5. Revoke the old key once all instances have switched.

Keep the overlap only as long as needed. If the old key has been exposed, revoke it promptly rather than waiting for a planned handover.

Rotate an existing key

Rotate replaces the secret on the same credential. It keeps the name, credential ID and expiry date, and updates its identifier. Rotation does not renew an expiring key.

1. Find the API key and click Rotate.
2. Review the warning and confirm the rotation.
3. Save the replacement secret from Save this secret now.
4. Update every application instance using that credential.
5. Verify the new key and check your application's requests.

The previous secret has no supported grace period. Applications still using it can fail authentication once the change reaches the API. Use a separate replacement key for a planned handover instead.

Credential changes are synchronized to the API when that integration is configured. They can take time to propagate; a dashboard confirmation alone does not prove the new key is accepted or the old key is rejected. If verification keeps failing, ask your workspace administrator to check synchronization.

Revoke a key

Revoke a key when an integration is retired, a replacement is in use, or the secret has been exposed.

1. Find the API key and click Revoke.
2. Check the credential name and confirm Revoke credential.
3. Confirm applications have stopped using it. For an exposed key, check that the API rejects it after the change propagates.

Revocation cannot be undone. The credential moves to Revoked, where its metadata is kept for reference. It cannot be rotated or used again; create a new key if needed. Other credentials in the workspace remain separate.

Review credential changes in Audit log →

If a control is missing

Creating, rotating and revoking credentials require the corresponding workspace permissions. Owners, Admins and Developers have these actions through their built-in roles. Viewing the list does not grant access to saved secrets.

Ask your workspace owner or administrator to review your role and permissions if an action is unavailable.

Best practices

• Name keys for the application and environment that use them.
• Keep secrets out of source control, browser code, request URLs, logs and shared screenshots.
• Review expiry dates and replace unused keys before they cause an outage.
• Verify replacements before retiring old keys during planned changes.