Creating and managing API keys

An API key lets your tools read or change data through the Round Robin API. Each key belongs to a workspace member and has its own permissions, secret, and call log.

You need: a Round Robin account and permission to edit the rotations the key covers. Workspace admins can create keys covering every rotation and inspect other members’ keys.

Create a key

Open Settings → API keys and select New key.
Enter a Name identifying the integration.
Under Permissions, choose the scopes the integration needs. Read access is required. Only workspace admins can select Webhook management.
Under Rotation access, choose Selected rotations or All rotations. All rotations requires workspace admin access and includes rotations created later.
Select Create key and copy its secret into your platform’s secret store. Select Secret saved, then Done.

The secret appears once. If you lose it, use Rotate secret and deploy the replacement.

Scopes and rotation access cannot be changed after creation. Create a new key if an integration needs different permissions. The owner’s permissions also limit what a key can do.

Inspect a key

Open a key under Settings → API keys. Key details contains its identifiers and secret dates. Access shows its permissions and owner.

Field	What to check
Key id	Copy this identifier when investigating a call. It is not the secret.
Contract version	The API contract assigned to this key.
Current secret ID and Previous secret ID	Secret identifiers, creation dates, last recorded use, and any expiry date. Secret values are not displayed.
Access	The granted scopes, covered rotations, and owner.

A blank Last recorded use does not prove a secret is unused. Confirm which secret each deployment holds before retiring it.

Investigate calls

The key owner and workspace admins can inspect Recent activity counters and Call records.

In Call records, set Period to Last 24 hours, Last 7 days, or Last 30 days. Periods use UTC hour boundaries and include the current hour.
Filter by Endpoint or Outcome. Endpoints show the HTTP method and route template, not individual resource addresses.
Select Refusals only to focus on failed calls.
Open a row to see Call details: its status, identifiers, selected request fields, and any Problem summary.

Counters cover the entire selected period and filters, including rows on other pages.

Counter	Meaning
Writes kept	Retained write calls, including failed writes.
Refusals	All recorded failed calls, including failures without a retained row.
Successful reads counted	Successful reads. These have no individual rows or request bodies.

The refusal row count above the call list tells you how many detailed failures remain. Counts overlap: a retained failed write contributes to both Writes kept and Refusals. Do not add the counters to calculate total traffic.

Call records and counts are retained for 30 days. Successful writes have individual rows.

For each key, the first 10,000 refusals with the same Endpoint and Outcome in a UTC hour have individual rows. After that, the log retains at most one further refusal per minute for that endpoint and outcome. A different endpoint or outcome has its own allowance, which resets at the next UTC hour.

The Refusals counter includes every recorded failure, even when high-volume repeated failures are sampled. Sampling does not limit API requests.

Call records and counts may be incomplete during a logging outage. API requests continue. Keep your integration’s logs if you need a complete record.

Read the request details

Request body shows selected request fields. Free text, URLs, and unsafe values are omitted. It is not a copy of the original request.

Body state	Meaning
Safe fields only.	The displayed JSON contains the selected fields available for this call.
Request body omitted.	No request body content is retained.
Request body exceeded the capture limit. Content omitted.	The selected content exceeds the capture limit, so no body content is retained.

Selected If-Match, Idempotency-Key, and Content-Type values appear when available. The log does not store the Authorization header, key secrets, or response bodies. Problem contains a status, code, and title for the failure, not the original response body.

There is no replay action. To retry, correct the integration and send a request from it using the API’s write conventions.

Export calls

Select Export as JSON to download the newest 1,000 matching stored calls. The export includes the selected period, filters, counters, and available request details. Successful reads and failures without a retained row appear only in the counters.

A Partial export message means more than 1,000 rows match. Narrow the period or filters before exporting again.

Resolve a refusal or missing record

State	What to do
Key switched off	Ask a workspace admin to select Enable, then deploy the new secret.
Old secret expired	Deploy the current secret.
Scope refused	Create a key with the required scope. Existing scopes cannot be changed.
Rotation out of reach	Use a key that covers the rotation.
Rate limited	Reduce the request rate and follow `Retry-After`. See rate limits.
If-Match missing	Read the resource and send its ETag in `If-Match`.
Resource changed	Read the latest resource before retrying the write.
Idempotency key reused	Use a fresh `Idempotency-Key` for a different request.
Calls unavailable	Select Refresh to try loading the log again.

If no rows match, select Clear filters or choose a longer period. Successful reads only appear in the counter. A refusal count without rows means no detailed records are available for that selection.

Calls using a disabled key or an expired previous secret can appear in the log. Calls with an unknown or revoked secret do not appear in this key’s log. For credential errors, see authentication.

Replace a secret without downtime

Select Rotate secret.
Select 7-day grace period, then Rotate secret. Both secrets work during deployment.
Copy the new secret and deploy it to every integration using this key.
Check Key details → Previous secret ID → Last recorded use for traffic still using the outgoing secret. Its Expires date is the deployment deadline.

The key keeps its identifier, scopes, and rotation access.

If the secret has leaked, select Immediate expiry, then Rotate and expire previous secret. The old secret stops working immediately. Deploy the replacement to restore access.

Disable or revoke a key

Disable stops API access. To restore access, a workspace admin selects Enable, then Enable with new secret. This transfers ownership to that admin and issues a new secret to deploy. After enabling, the secret that was current before the key was disabled becomes valid again for seven days.

Revoke, followed by Revoke key, permanently invalidates the key’s secrets. To restore the integration, create a new key and deploy its secret. Calls using a revoked secret receive an unknown credential refusal.

Revoked keys remain under Show revoked keys for 90 days. The key page displays Record expiry. This does not extend the 30-day call-log retention.

Restore access after the owner leaves

When an owner leaves the Slack workspace, their keys are disabled automatically. A workspace admin can open the key and select Enable, then Enable with new secret. The admin takes ownership and receives a new secret to deploy.

Stay within the key limit

A workspace can hold 25 enabled or disabled keys. Revoked keys do not count towards the limit. Revoke keys for retired integrations to free a place.

Give each integration its own key so its access can be stopped independently.

Next steps

Authenticating with an API key: send a secret and resolve credential refusals
Scopes and access: choose the permissions and rotations a key covers
API conventions: retry writes with preconditions and idempotency keys