Create and manage API credentials

API credentials represent organization-owned service accounts. They are appropriate for internal automation and server-to-server integrations where an interactive OAuth consent flow is unnecessary.

Before you begin

You need access to the organization and the Manage API credentials capability. The active plan must include Public API access. If API & Webhooks controls are missing, ask an organization owner to check your role. If the section displays a plan notice, review the organization subscription instead of repeatedly submitting the form.

Create a service account

1. Open the organization, then go to Organization settings → API & Webhooks.
2. Enter a recognizable name such as Reporting production or Task sync staging.
3. Select only the scopes the integration requires. Read scopes do not grant write access; choose the matching :write scope only when the integration must create or change data.
4. If you select chat scopes, choose specific organization channels or explicitly allow all current and future organization channels. Direct messages are excluded in every case.
5. Choose an expiry period and select Create token.
6. Copy the riiw_sa_ token immediately and store it in a secrets manager. RIIW does not display the complete token again.

Do not place a token in browser code, source control, screenshots, analytics, URLs, or support tickets. Give staging and production separate service accounts so each environment can be rotated or revoked independently.

Understand scopes

Scopes are additive. Typical read integrations use organization:read, projects:read, and tasks:read. Task automation needs tasks:write; document content requires docs:content:read; downloading file bytes requires files:content:read. There is no member-write scope, so service accounts cannot invite or remove people.

A credential with write scopes can perform supported Public API mutations. It still cannot bypass organization boundaries, project ownership checks, workflow transitions, plan limits, quotas, ETags, or idempotency requirements.

Rotate a credential

Rotate a token when it approaches expiry, when ownership changes, or when exposure is suspected. Select Rotate beside the credential, confirm the action, and copy the replacement token. Rotation updates the existing credential rather than creating a second service account.

Update the consumer promptly and verify a harmless read request. The previous token is no longer the active credential. If the credential had become expired, it remains visible so an authorized administrator can rotate it without recreating webhook ownership.

Revoke a credential

Use Revoke when the integration must permanently lose access. Revocation cannot be undone and removes stored authentication material. Webhook endpoints owned by that service account are also revoked and pending deliveries for those endpoints are cancelled.

Temporary platform or organization pauses are different from revocation. During a pause, the credential remains present and can resume after an administrator restores service.

Troubleshooting

• No write access: confirm the token has the exact :write scope required by the operation.
• Plan unavailable: an organization owner must enable a plan containing Public API.
• Integration disabled: wait for the operational pause to be lifted; do not rotate the token to work around it.
• Token not shown: complete secrets are displayed only at creation or rotation. Rotate the credential if the value was not copied.
• Resource not found: verify the organization and resource IDs. Cross-organization lookups intentionally appear not found.

Continue with Authenticate with the Public API after storing the token securely.