Skip to main content
API keys authenticate server-side requests and bind each request to one Signal project. Use a separate restricted key for each application, environment, or job that calls Signal.

Create the key

1

Open API keys

Select the project, then open API keys in the main navigation.
2

Name the caller

Use a name that identifies the service and environment, such as checkout production or billing worker staging. Names can contain up to 100 characters.
3

Choose an expiry

Choose no expiry, 7 days, 30 days, 90 days, or 1 year. Short-lived keys reduce exposure but require a rotation process.
4

Grant permissions

Select at least one permission. Grant only the actions the caller performs.
5

Copy the secret

Create the key and copy the raw ap_signal_... value immediately. Signal stores and later displays only a masked form.

Customer permissions

A service that only sends mail normally needs Emails: Send and nothing else. Give read access to a separate operational tool if the sender never reads message state.

Store and use the key

Store the key in a deployment secret manager or protected environment variable. REST requests send it as a bearer token:
SMTP uses apikey as the username and the Signal key as the password.

Understand the key list

The dashboard shows the masked key, permission set, status, creation time, last-used time, and total request count. Use these signals to find unused credentials and confirm that a rotated caller moved to the new key.

Rotate a key without downtime

  1. Create a replacement with the same or narrower permissions.
  2. Store it as a new secret version.
  3. Deploy callers with the replacement.
  4. Confirm the new key’s last-used value changes.
  5. Delete the old key.
Deleting a key takes effect immediately. Requests that still carry it will fail authentication.
If a key appears in a repository, browser bundle, log, screenshot, or support message, treat it as compromised. Create a replacement and delete the exposed key instead of trying to hide the existing value.