curl --request POST \
--url https://api.coderabbit.ai/v1/users/seats \
--header 'Content-Type: application/json' \
--header 'x-coderabbitai-api-key: <api-key>' \
--data '
{
"action": "assign",
"user_ids": [
"121358802",
"22605247"
]
}
'{
"status": "success",
"succeeded": [
"121358802",
"22605247"
],
"failed": []
}{
"error": {
"code": "BATCH_SIZE_EXCEEDED",
"message": "Maximum 500 users per request"
}
}{
"error": {
"code": "UNAUTHORIZED",
"message": "Invalid or inactive API key"
}
}{
"error": {
"code": "NOT_ADMIN",
"message": "Only administrators can perform seat management operations"
}
}{
"error": {
"code": "LEGACY_API_KEY",
"message": "You are using a legacy API key. We are deprecating use of legacy keys. Regenerate a new API key and retry the request."
}
}{
"error": {
"code": "RATE_LIMIT_EXCEEDED",
"message": "Rate limit exceeded. Max 10 requests per 60 seconds"
}
}{
"error": {
"code": "INTERNAL_ERROR",
"message": "Internal server error while listing users"
}
}Seats
Bulk assign or unassign seats for up to 500 users. The request format depends on the type of API key used. Organization and self-hosted instance API keys address users by provider user ID with the action + user_ids format, where the action field determines the operation type. Workspace API keys address users by email or CodeRabbit user ID (cr_user_id) with the members format, where each entry declares its desired seat state via seat_assigned. Sending the action + user_ids format with a workspace API key (or the members format with an organization key) fails with an INVALID_REQUEST error.
curl --request POST \
--url https://api.coderabbit.ai/v1/users/seats \
--header 'Content-Type: application/json' \
--header 'x-coderabbitai-api-key: <api-key>' \
--data '
{
"action": "assign",
"user_ids": [
"121358802",
"22605247"
]
}
'{
"status": "success",
"succeeded": [
"121358802",
"22605247"
],
"failed": []
}{
"error": {
"code": "BATCH_SIZE_EXCEEDED",
"message": "Maximum 500 users per request"
}
}{
"error": {
"code": "UNAUTHORIZED",
"message": "Invalid or inactive API key"
}
}{
"error": {
"code": "NOT_ADMIN",
"message": "Only administrators can perform seat management operations"
}
}{
"error": {
"code": "LEGACY_API_KEY",
"message": "You are using a legacy API key. We are deprecating use of legacy keys. Regenerate a new API key and retry the request."
}
}{
"error": {
"code": "RATE_LIMIT_EXCEEDED",
"message": "Rate limit exceeded. Max 10 requests per 60 seconds"
}
}{
"error": {
"code": "INTERNAL_ERROR",
"message": "Internal server error while listing users"
}
}Manage Seats
Request format by API key type
The request body schema depends on the type of API key you authenticate with:| API key type | Request format | Users addressed by |
|---|---|---|
| Organization | action + user_ids | Provider user ID |
| Self-hosted instance | action + user_ids | Provider user ID |
| Workspace | members | Email or cr_user_id |
action + user_ids format — sending it fails with INVALID_REQUEST: Invalid input: expected array, received undefined. Use the members format instead, where each entry declares its desired seat state with seat_assigned.curl --request POST \
--url 'https://api.coderabbit.ai/v1/users/seats' \
--header 'x-coderabbitai-api-key: <workspace-api-key>' \
--header 'content-type: application/json' \
--data '{"members":[{"email":"user@example.com","seat_assigned":true}]}'
email or cr_user_id (the user_id returned by GET /v1/users) — at least one is required, and cr_user_id takes precedence when both are provided. Use cr_user_id to address members who have no email; unknown IDs fail that entry with USER_NOT_FOUND in the response’s failed array.Authorizations
API key for authentication. You can create an API key from the CodeRabbit dashboard.
Headers
Your CodeRabbit API key
Body
- Organization / self-hosted instance key
- Workspace key
Request to manage user seats with an organization or self-hosted instance API key. Users are addressed by provider user ID.
Response
Operation completed (check status field for partial failures). The succeeded and failed entries echo the identifiers used in the request: provider user IDs for organization and self-hosted instance keys; for workspace keys, whichever identifier each member supplied (cr_user_id when provided, otherwise email).
Response for bulk operations with partial success model
Operation status: 'success' if all succeeded, 'partial_success' if some succeeded, 'failure' if all failed
success, partial_success, failure Array of user IDs that were successfully processed
Array of failures with error details
Show child attributes
Show child attributes
Was this page helpful?