Coda User Management API Guide

Auth method: API Key (Bearer token in Authorization header)

Setup steps

1. Log in to Coda and navigate to your Account Settings.
2. Go to the 'API settings' section.
3. Click 'Generate API token' and copy the token.
4. Include the token in all API requests as: Authorization: Bearer

Required scopes

Get current user (whoami)

• Method: GET
• URL: https://coda.io/apis/v1/whoami
• Watch out for: Returns the identity of the API token owner, not an arbitrary user. No user-lookup by ID in the REST API.

Request example

GET /apis/v1/whoami
Authorization: Bearer <token>

Response example

{
  "name": "Jane Doe",
  "loginId": "jane@example.com",
  "pictureLink": "https://...",
  "tokenName": "My Token"
}

List doc access members

• Method: GET
• URL: https://coda.io/apis/v1/docs/{docId}/acl/permissions
• Watch out for: Only returns permissions for the specific doc. There is no org-wide user list endpoint in the REST API.

Request example

GET /apis/v1/docs/{docId}/acl/permissions
Authorization: Bearer <token>

Response example

{
  "items": [
    {"id":"...","principal":{"type":"email","email":"user@example.com"},"access":"write"}
  ],
  "nextPageToken": "..."
}

Add doc permission

• Method: POST
• URL: https://coda.io/apis/v1/docs/{docId}/acl/permissions
• Watch out for: Sends an email invitation; does not provision the user in the org. Use SCIM for org-level provisioning.

Request example

POST /apis/v1/docs/{docId}/acl/permissions
{
  "access": "write",
  "principal": {"type": "email", "email": "user@example.com"}
}

Response example

{
  "id": "AbCdEf",
  "access": "write",
  "principal": {"type":"email","email":"user@example.com"}
}

Delete doc permission

• Method: DELETE
• URL: https://coda.io/apis/v1/docs/{docId}/acl/permissions/{permissionId}
• Watch out for: permissionId must be retrieved from the list permissions endpoint first.

Request example

DELETE /apis/v1/docs/{docId}/acl/permissions/{permissionId}
Authorization: Bearer <token>

Response example

HTTP 204 No Content

SCIM – List users

• Method: GET
• URL: https://coda.io/scim/v2/Users
• Watch out for: Requires Enterprise plan and a separately generated SCIM token (not the same as the REST API token).

Request example

GET /scim/v2/Users?startIndex=1&count=100
Authorization: Bearer <scim_token>

Response example

{
  "schemas":["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
  "totalResults":2,
  "Resources":[{"id":"...","userName":"user@example.com","active":true}]
}

SCIM – Create user

• Method: POST
• URL: https://coda.io/scim/v2/Users
• Watch out for: SAML SSO must be fully configured before SCIM provisioning will work. Only one SCIM token is valid at a time.

Request example

POST /scim/v2/Users
{
  "schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],
  "userName":"newuser@example.com",
  "name":{"givenName":"New","familyName":"User"},
  "active":true
}

Response example

{
  "id": "scim-uid-123",
  "userName": "newuser@example.com",
  "active": true
}

SCIM – Update user (deactivate)

• Method: PATCH
• URL: https://coda.io/scim/v2/Users/{scimId}
• Watch out for: Deactivating a user removes their access but does not delete their content. Reassign docs before deprovisioning.

Request example

PATCH /scim/v2/Users/{scimId}
{
  "schemas":["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations":[{"op":"replace","path":"active","value":false}]
}

Response example

{
  "id": "scim-uid-123",
  "userName": "user@example.com",
  "active": false
}

SCIM – Delete user

• Method: DELETE
• URL: https://coda.io/scim/v2/Users/{scimId}
• Watch out for: Hard-deletes the user from the org. Content ownership should be transferred beforehand.

Request example

DELETE /scim/v2/Users/{scimId}
Authorization: Bearer <scim_token>

Response example

HTTP 204 No Content

• Rate limits: Coda enforces per-token rate limits. The default limit is 10 requests per second per token. Limits may vary by endpoint and plan.
• Rate-limit headers: Yes
• Retry-After header: Yes
• Rate-limit notes: When rate limited, the API returns HTTP 429. The Retry-After header indicates how many seconds to wait. X-RateLimit-Limit and X-RateLimit-Remaining headers are included in responses.
• Pagination method: token
• Default page size: 25
• Max page size: 500
• Pagination pointer: pageToken

• Webhooks available: No
• Webhook notes: Coda does not offer native outbound webhooks for user-management events (e.g., user added, removed, deprovisioned). Automations within docs can POST to external URLs but are doc-scoped, not org/user-scoped.
• Alternative event strategy: Poll the SCIM /Users endpoint or use Coda's doc-level Automations to trigger external HTTP requests on row/data changes.

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Enterprise

• Endpoint: https://coda.io/scim/v2

• Supported operations: GET /Users (list users), GET /Users/{id} (get user), POST /Users (create user), PATCH /Users/{id} (update user attributes or active status), PUT /Users/{id} (replace user), DELETE /Users/{id} (delete user), GET /Groups (list groups), POST /Groups (create group), PATCH /Groups/{id} (update group membership), DELETE /Groups/{id} (delete group)

Limitations:

• Enterprise plan required; not available on Free, Pro, or Team plans.
• SAML SSO must be configured and active before SCIM can be enabled.
• Only one SCIM token is valid at a time; generating a new token invalidates the previous one.
• Supported IdPs with documented integration: Okta, Microsoft Entra ID (Azure AD). Google Workspace and OneLogin not officially documented.
• Deactivating a user does not transfer doc ownership automatically.
• SCIM token is separate from the REST API token and generated in the Enterprise admin settings.

Three integration patterns cover the primary lifecycle operations. For org-level provisioning via Okta or Entra ID, the SCIM flow requires SAML SSO to be fully active first; the IdP sends POST /scim/v2/Users on hire and PATCH /scim/v2/Users/{scimId} with active: false on departure.

For offboarding, deactivation via SCIM revokes SSO access but does not transfer or delete the user's docs - content remains owned by the deactivated account until an admin manually reassigns it.

For doc-level access grants without org membership, POST to /apis/v1/docs/{docId}/acl/permissions with the collaborator's email; this sends an invitation and does not consume a Maker seat or add the user to the org.

There is no org-wide user list endpoint in the REST API - enumerating all workspace members requires the SCIM /Users endpoint, making SCIM the authoritative source for building or maintaining an identity graph across the Coda workspace.

Provision a new employee via SCIM (Okta)

1. Ensure SAML SSO is configured in Coda Enterprise admin settings.
2. In Coda admin settings, generate a SCIM token under 'SCIM provisioning'.
3. In Okta, add the Coda SCIM app and enter the SCIM base URL (https://coda.io/scim/v2) and the token.
4. Assign the new employee to the Coda app in Okta.
5. Okta sends POST /scim/v2/Users with the user's email, name, and active: true.
6. Coda creates the user account; the user can log in via SSO.

Watch out for: If the SCIM token is regenerated in Coda after Okta is configured, Okta provisioning will fail with 401 until the new token is updated in Okta.

Deprovision a departing employee

1. In Okta (or Entra ID), remove or deactivate the user from the Coda app assignment.
2. The IdP sends PATCH /scim/v2/Users/{scimId} with active: false.
3. Coda deactivates the user, revoking SSO access.
4. Optionally, an admin manually transfers doc ownership in Coda before or after deactivation.
5. To fully delete, send DELETE /scim/v2/Users/{scimId} or trigger from IdP if configured.

Watch out for: Deactivation does not transfer or delete the user's docs. Content remains owned by the deactivated account until manually reassigned by an admin.

Grant a collaborator access to a specific doc via REST API

1. Generate a REST API token from Coda Account Settings.
2. Identify the target docId from the doc URL or GET /apis/v1/docs.
3. POST to /apis/v1/docs/{docId}/acl/permissions with the collaborator's email and desired access level (read, write, comment).
4. Coda sends an email invitation to the collaborator.
5. Verify the permission was added with GET /apis/v1/docs/{docId}/acl/permissions.

Watch out for: This grants doc-level access only; it does not add the user to the Coda org or consume a Maker seat. The invited user must accept the invitation to access the doc.

The most common integration mistake is conflating the REST API with org management capability. The REST API has no endpoint to list org members, provision users, or change workspace roles - those operations exist only in SCIM.

Teams that build on the REST API alone will hit a hard ceiling when they need to enumerate users or automate offboarding.

A second trap is token lifecycle: because one SCIM token invalidates the previous, any rotation event in Coda admin must be immediately reflected in the IdP configuration or provisioning will fail with 401 errors that may not surface until the next sync cycle.

Coda also offers no native webhooks for user-management events at the org level; detecting provisioning state changes requires polling SCIM /Users or relying entirely on IdP-push events.

Integrations that need a reliable identity graph - mapping users across every app in the stack - should treat the SCIM endpoint as the sole source of truth for Coda membership state and build polling or IdP-event-driven refresh logic accordingly.