Create and use API keys

API keys let external systems — a CRM sync, a reporting job, a Zapier automation — talk to RadarSend programmatically. Each key belongs to a service account (not a person), carries its own permissions (scopes), and can be rotated or revoked without touching your other integrations.

Create an API key#

Go to Settings → Developer → API keys.

1. In Service account name, name the integration that will use the key (for example, Salesforce Sync). This is how you’ll recognize the key later in the list.
2. Add an optional Description — a note for future admins about what the key is for.
3. Under Permissions, choose the access this integration needs (see Scopes & permissions below).
4. Click Generate key.

The new key appears once, in a highlighted box labeled “New key — copy now, it won’t be shown again.” Click Copy and store it somewhere safe (a secrets manager or your integration’s config). RadarSend only keeps a hashed copy — if you lose the key, you can’t recover it, you can only rotate to a new one.

After that, the key shows up in the table below, identified by its service account name and a masked prefix (for example, qs_a1b2c3d4_••••). The table also shows the key’s permissions, when it was Last used, and when it was Created.

Scopes & permissions#

Grant the minimum access each integration needs. The permission picker offers three starting points:

• Full access — grants everything (the * scope). Convenient, but the widest blast radius if the key leaks.
• Read-only — every read permission, no writes.
• Custom — expand each resource and tick exactly the permissions you want.

Custom permissions are organized by resource:

Two rules to keep in mind:

• Write implies read. Granting Write on a resource also allows reading it — the picker marks the read row as implied by write.
• Schedule is separate. For broadcasts, Write lets a key create and edit drafts, but it does not let the key send. Only add Schedule for integrations that truly need send authority; leave final scheduling to your team otherwise.

A good default is one key per integration, each scoped to just its job — a reporting job needs only Reports (Read); a CRM sync typically needs Contacts (Write) and maybe Custom fields (Read).

Use your key#

Send the key in the X-API-Key header on every request. All API requests are tenant-scoped in the URL:

https://YOUR-APP/t/YOUR-TENANT-SLUG/api/...
Copy

Example — list your email types:

curl -X GET \
  "https://app.example.com/t/acme/api/email-types" \
  -H "X-API-Key: YOUR-API-KEY"
Copy

Replace acme with your workspace’s tenant slug and YOUR-API-KEY with the secret you copied. API keys act as service accounts: they can reach the public API but cannot use admin-only surfaces like user management, billing, tenant settings, or API-key management — those require a logged-in admin session.

Rotate or revoke a key#

Both actions live in the row’s Rotate / Revoke buttons and require you to type a short confirmation.

• Rotate issues a new secret and revokes the current one immediately — any service still using the old key stops working. Rotate on a schedule, when a vendor changes, or if a secret may have leaked. The new key is shown once, just like at creation, so copy it before you close the panel.
• Revoke permanently disables the key. Any service using it stops working, and this cannot be undone. Use it to retire an integration or shut down a leaked key.

Common issues#

• “I didn’t copy the key in time.” The secret is shown only once, at creation (and again after a rotate). It can’t be retrieved later — Rotate the key to get a fresh secret, then update your integration.
• INSUFFICIENT_SCOPE (missing a required scope). The key is valid but wasn’t granted the permission that route needs (for example, scheduling a broadcast requires Broadcasts → Schedule). Create or re-scope a key with the needed permission.
• API_KEY_FORBIDDEN (can’t access this route). You’re pointing an API key at an admin-only or session-only endpoint. Service-account keys only reach the public API.
• UNAUTHORIZED (authentication required). The X-API-Key header is missing or the key has been revoked. Check the header and confirm the key still exists in the table.

Good to know#

• Keys bypass 2FA and act with their service-account permissions. Treat them like passwords: never commit them to source control, share them in tickets, or embed them in client-side code.
• Prefer narrow scopes and one key per integration. A leaked key is only as dangerous as the scopes you gave it.
• For endpoints, request/response shapes, and detailed scope planning, see the full API reference — start with Authentication and Scopes & access planning.