API keys

API keys authenticate non-browser access to your EmailBuilder account. The Gmail add-on, Outlook add-in, and MCP server all use API keys.

Generating a key

1. Go to Account → Integrations → API Keys.
2. Click Generate new key.
3. Give it a name describing its purpose: Gmail add-on, Claude MCP, Internal automation.
4. Click Create. The key is shown to you once — copy it now.

Keys are prefixed with eb_ so they're recognisable in logs:

eb_00f49845ccb214259ca6ebb0a1080e61354cd434dd1ec080bacd0de15cbace87

After you close the dialog, the full key is never shown again. Store it in a password manager or your team's secrets store.

How keys are stored

Keys are stored as SHA-256 hashes on our side, not in plaintext. We can't retrieve a lost key — if you lose one, generate a new one and revoke the old.

Each key tracks:

• Name — what you called it on creation.
• Last used — timestamp of the most recent successful request.
• Created — when it was generated.

The Last Used column is the easiest signal for cleanup — anything idle for months is a candidate for revocation.

Naming convention

A clean naming convention helps you revoke selectively without breaking working integrations:

• Per integration: Gmail add-on, Outlook add-in, Claude MCP — laptop, Claude MCP — server.
• Per environment: Production — webhook handler, Staging — webhook handler.
• Per person: Alice — Claude Desktop, Bob — Cursor.

Avoid generic names like key1 or api. When you need to revoke quickly (suspected leak, ex-employee), specific names save time.

Revoking a key

On the API Keys page, click Revoke next to any key. Revocation:

• Is immediate — the key stops authenticating on the next request.
• Cannot be undone — you can't reinstate a revoked key. Generate a new one if you revoke by mistake.
• Affects every device or integration using that key. Use named keys so you can revoke selectively without breaking unrelated integrations.

Permissions

Every key acts as your account — there's no per-key scope today. A key generated by an Admin has Admin permissions; a key generated by an Editor has Editor permissions. Keys inherit the role of the user who generated them at the time of authentication.

For high-trust automations (production sends, billing changes), generate the key from an Admin or Owner account. For day-to-day work (template editing, AI assistance), an Editor-role user is sufficient and limits blast radius if the key leaks.

Key rotation

Best practice for production systems:

1. Generate a new key.
2. Update your integration to use the new key.
3. Verify it works (check the Last Used timestamp on the new key).
4. Revoke the old key.

There's no automatic rotation today — you do this manually when convenient. We recommend rotating production keys at least quarterly.

What keys can't do

• Manage billing. The customer portal requires a browser session — keys can't change plans, update payment methods, or download invoices.
• Manage other API keys. Generating, listing, or revoking keys requires a browser session for security reasons.
• Send via REST API. There's no public REST send endpoint today. Use the MCP server or the Gmail/Outlook add-ons for programmatic-ish sending. A public REST API is on our roadmap.

If you suspect a key was leaked

1. Revoke the key immediately.
2. Check the key's Last Used timestamp — if it's after the suspected leak, treat it as compromised.
3. Generate a new key with a different name.
4. Update integrations.
5. Audit recent activity in the affected integrations (e.g. unexpected templates, sends, integration changes).

Keys are scoped to your account — a leaked key can't access other accounts. The damage ceiling is what your own account can do. Still, rotate promptly.