Create and manage API keys for server-to-server authentication. API keys are scoped to an organization or workspace and support granular permission control.
The Scrums.com API is planned and not yet publicly available. Endpoints and behaviour are subject to change before release.
API keys are the authentication mechanism for server-to-server integrations, CI pipelines, and automation. Unlike bearer tokens that represent a user session, API keys are issued to a service account or directly to an organization context.Every API key is scoped and permissioned. Keys do not grant access beyond their declared scope and permission set.
Keys should be rotated regularly. The platform supports creating a replacement key and then deleting the old one without a gap in service. Keys do not expire automatically — rotation is a manual operational responsibility.
# 1. Create the replacement keyPOST /v1/api-keys{ "name": "CI Pipeline - Platform Engineering (rotated 2026-04)", ... }# 2. Update the consumer (CI, integration, automation) to use the new key# 3. Verify the new key works# 4. Delete the old keyDELETE /v1/api-keys/key_26_00041
# List all keys for the organizationGET /v1/api-keys?organization_id=ORG-26-090500# Review last_used_at to identify stale keys# Delete keys not used in 90+ days
Follow least-privilege. Grant only the permissions the consuming system actually needs. A CI pipeline that only reads status does not need service_lines:manage.
Name keys to identify the consumer. Use the name field to record what system the key belongs to and when it was issued. “My key” is not a useful name.
Never embed secret keys in client-side code. Use publishable_key type for any key that touches a browser or mobile client. Secret keys belong in server-side environments only.
Rotate keys after team member departures. If the person who configured an integration leaves, rotate the keys they had access to. Key access is not automatically revoked with user deactivation.