# API Keys and Authorized Apps

> API keys and authorized apps control how outside systems access a workspace. This guide explains when to use each credential type, how to create credentials safely, and when to revoke access.

- Human page: https://mailrith.com/docs/api-keys-and-authorized-apps
- Markdown page: https://mailrith.com/docs/api-keys-and-authorized-apps.md
- Category: Getting Started
- Reading time: 8 min read
- Last updated: 2026-06-13
- Related keywords: API Keys and Authorized Apps, API Keys and Authorized Apps documentation, Getting Started, Getting Started documentation, Mailrith documentation, Mailrith help, Keys vs Authorized Apps, Create an API Key, Rotate or Revoke Access, Review Authorized Apps, Credential Safety Checklist, Account Settings, Subscribers, Team Members

## AI Agent Notes
- Use this article as step-by-step Mailrith product guidance, not as legal, financial, or deliverability advice unless the article says so.
- Preserve exact Mailrith UI labels from the steps when explaining a workflow.
- Prefer Mailrith's product term Subscribers when referring to people on an email list.

## What this guide covers
Create workspace API keys, choose read-only or read-write access, rotate or revoke keys, and review connected OAuth apps from Integrations.

## Sections
- Keys vs Authorized Apps
- Create an API Key
- Rotate or Revoke Access
- Review Authorized Apps
- Credential Safety Checklist

## Visual Reference
![Mailrith account settings page showing account-level settings.](https://mailrith.com/docs/screenshots/account-settings.png)

Settings includes API keys for direct integrations. Authorized apps are reviewed from the Integrations page.

## API Keys and Authorized Apps Are Different

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

- **Use an API key** when your own website, backend, script, or internal tool needs direct access to Mailrith.
- **Use an authorized app** when a third-party tool asks you to connect Mailrith and sends you to a Mailrith approval screen.

Both credential types are workspace-scoped. A key or authorized app can access only the workspace it was created or approved for. You do not need to send a separate workspace choice when you use the public API because the credential already identifies the workspace.

## Create an API Key

Create API keys from **Settings** on the **API Keys** tab. Create a separate key for each integration so you can rotate or revoke one integration without affecting the others. For example, use one key for your website sign-up form, another key for a CRM sync, and another key for an imported subscriber data script. If you are building the integration yourself, create the key first, and then follow the [Developer Quickstart](https://mailrith.com/developers/quickstart.md).

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** that the integration needs to access.
5. Enter a **Name** that identifies the system that will use the key.
6. Choose **Access Level**. Use **Read Only** for reporting or syncs that only read records. Use **Read and Write** only when the integration must create or change records.
7. Choose **Expiration**. Select an expiration date for a temporary key. Select **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 Mailrith does not show the full secret again. If you lose the full key, rotate the key or create a new key, and then update the integration with the new secret.

## Rotate or Revoke API Access

Rotating a key replaces the secret value for an API key while keeping the integration record in place. Revoking a key disables 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 has ended, or you want access to stop immediately.
- **Do not rotate revoked keys.** After a key is revoked, create a new key if the integration needs access again.

Before you rotate a key, confirm that the person responsible for the integration is ready to update the stored secret in the connected system. Rotation is successful only after the connected system uses the new key. If the integration keeps using the old key after rotation, the integration will stop working. If that person should no longer have workspace access, remove or change their access through [Team Members](https://mailrith.com/docs/team-members.md).

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 the integration should keep working with a new secret value.
4. Copy the replacement key from the dialog, update the connected system with the new key, and confirm the connected system works before you consider the rotation complete.
5. Click **Revoke** when the integration should stop working immediately.

## Review Authorized Apps

Authorized apps appear on the **Integrations** page after an outside application connects to Mailrith through an OAuth approval flow. The list shows the app name, the workspace the app can access, the permissions the app requested, the authorization time, and whether the authorization is active or revoked.

1. Click **Integrations** in the left sidebar.
2. Click the **Authorized Apps** card.
3. On the **Authorized Apps** page, check the app name, workspace, access, activity, and status for each connected app.
4. Click **Revoke** for any active app that should no longer access the workspace.
5. Confirm the revoke action in the **Revoke Authorized App** dialog.

Revoke an app when your team no longer uses it. Revoking an authorized app stops future access from that app, but it does not delete Mailrith records that the app already created or updated. If you reconnect the same app later, the app must go through the authorization flow again. For account-level access review, also check [Settings](https://mailrith.com/docs/account-settings.md).

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

## Credential Safety Checklist

- Name each key after the system that uses it, not after the person who creates it.
- Store full API key values in a password manager, secret manager, or server environment variable. Do not paste API key values into shared documents or chat channels.
- Give each integration the smallest access level that still lets the integration do its required work.
- Review keys and authorized apps whenever a contractor leaves, an agency handoff occurs, or a connected tool is retired.
- Revoke any credential or authorized app you do not recognize. Create a new credential only if a real integration stops working and you can identify who owns the integration.

## Related Guides
- [Account Settings](https://mailrith.com/docs/account-settings.md): Settings covers your account identity, password security, billing plan, API keys, and Danger Zone actions. These settings apply to every workspace you operate.
- [Subscribers](https://mailrith.com/docs/subscribers.md): The Subscribers page is the main workspace for your Subscriber list. Use it to search Subscribers, filter Subscribers by status, run bulk actions, import and export CSV files, and review source-specific Subscriber history.
- [Team Members](https://mailrith.com/docs/team-members.md): Team Members gives you detailed control over which workspaces each person can access and what each person can do in those workspaces, without granting broad access to everything.
