API Keys and Authorized Apps

API Keys and Authorized Apps Are Different

Mailrith has two ways for outside systems to connect to a workspace. API keys are direct credentials that you create inside Settings. Authorized apps are third-party applications that a user approved through Mailrith's OAuth authorization screen.

• Use an API key when your own website, backend, script, or internal tool needs to work with Mailrith directly.
• Use an authorized app when a third-party tool asks you to connect Mailrith and sends you through a Mailrith approval screen.

Both are workspace-scoped. That means a key or authorized app can work only with the workspace it was created or approved for. You do not need to pass a separate workspace choice when using the public API; the credential already decides the workspace.

Create an API Key

API keys are created from Settings on the API Keys tab. Create a separate key for every integration. For example, use one key for your website sign-up form, another key for a CRM sync, and another key for a data import script. If you are building the integration yourself, start with the Developer Quickstart after the key is created.

1. Click Settings in the left sidebar.
2. Click the API Keys tab.
3. In Integration Credentials, click Generate API Key.
4. In the Generate API Key drawer, choose the Workspace you want the integration to access.
5. Enter a Name that explains what system will use the key.
6. Choose Access Level. Use Read Only for reporting or syncs that only read data. Use Read and Write only when the integration must create or change data.
7. Choose Expiration. Use an expiration date when the key is temporary, and use Never expires only for long-running systems that your team actively owns.
8. Click Generate.
9. In the Save Your API Key dialog, copy the full key immediately. Mailrith shows the full key only once.

After you close the key dialog, Mailrith keeps enough information to identify the key, but it does not show the full secret again. If you lose the full value, rotate the key or create a new one and update the integration.

Rotate or Revoke API Access

Rotating means replacing the secret value for an API key while keeping the integration concept in place. Revoking means disabling access so the key can no longer be used.

• Rotate a key when the system still needs access but the secret may have been seen by the wrong person, stored in the wrong place, or used for too long.
• Revoke a key when the integration is no longer used, a vendor relationship ended, or you want access to stop immediately.
• Do not rotate revoked keys. Once a key is revoked, create a new key if access needs to be restored.

Before rotating a key, make sure the person responsible for the integration is ready to update the stored secret. If the integration keeps using the old key after rotation, it will stop working. If that person no longer belongs in the workspace, remove or change their access through Team Members.

1. Click Settings in the left sidebar and open the API Keys tab.
2. Use Search API keys to find the key by name, owner, workspace, or purpose.
3. Click Rotate when you want the integration to keep working with a new secret value.
4. Copy the replacement key from the dialog and update the connected system before treating the rotation as finished.
5. Click Revoke when you want the integration to stop working immediately.

Review Authorized Apps

Authorized apps appear in Settings when an outside application has been connected to Mailrith through an OAuth approval flow. The list shows the app name, the workspace it can access, the permissions it requested, when it was authorized, and whether the authorization is active or revoked.

If you no longer use an app, revoke it. Revoking an authorized app stops future access from that app but does not delete the Mailrith data the app already created or updated. If you reconnect the same app later, it will go through the authorization flow again. For account-level access review, also check Settings.

If the authorized apps list is empty, no OAuth apps are currently connected to the selected workspace. That is a normal state for teams that only use direct API keys.

Credential Safety Checklist

• Name every key after the system that owns it, not after the person creating it.
• Store full API key values in a password manager, secret manager, or server environment variable. Do not paste them into shared documents or chat channels.
• Give integrations the smallest access level that still lets them do their job.
• Review keys and authorized apps whenever a contractor leaves, an agency handoff occurs, or a connected tool is retired.
• Revoke anything you do not recognize, then create a new credential only if a real integration stops working and you can identify who owns it.