Render User Management API Guide

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

Setup steps

1. Log in to the Render dashboard.
2. Navigate to Account Settings > API Keys.
3. Click 'Create API Key', provide a name, and copy the generated key.
4. Include the key in all API requests as: Authorization: Bearer {API_KEY}

List team members

• Method: GET
• URL: https://api.render.com/v1/teams/{teamId}/members
• Watch out for: Requires the API key to belong to an owner or admin of the team.

Request example

GET /v1/teams/{teamId}/members?limit=20
Authorization: Bearer {API_KEY}

Response example

[
  {
    "member": {
      "email": "user@example.com",
      "name": "Jane Doe"
    },
    "role": "admin",
    "status": "accepted"
  }
]

Add (invite) team member

• Method: POST
• URL: https://api.render.com/v1/teams/{teamId}/members
• Watch out for: Sends an email invitation; user must accept before status changes to 'accepted'.

Request example

POST /v1/teams/{teamId}/members
Authorization: Bearer {API_KEY}
Content-Type: application/json

{"email":"newuser@example.com","role":"member"}

Response example

{
  "member": {
    "email": "newuser@example.com"
  },
  "role": "member",
  "status": "pending"
}

Update team member role

• Method: PUT
• URL: https://api.render.com/v1/teams/{teamId}/members/{memberId}
• Watch out for: Only the team owner can change roles to/from 'owner'.

Request example

PUT /v1/teams/{teamId}/members/{memberId}
Authorization: Bearer {API_KEY}
Content-Type: application/json

{"role":"admin"}

Response example

{
  "member": {"email": "user@example.com"},
  "role": "admin",
  "status": "accepted"
}

Remove team member

• Method: DELETE
• URL: https://api.render.com/v1/teams/{teamId}/members/{memberId}
• Watch out for: Cannot remove the sole owner of a team.

Request example

DELETE /v1/teams/{teamId}/members/{memberId}
Authorization: Bearer {API_KEY}

Response example

HTTP 204 No Content

Retrieve authenticated user

• Method: GET
• URL: https://api.render.com/v1/user
• Watch out for: Returns the user associated with the API key, not an arbitrary user.

Request example

GET /v1/user
Authorization: Bearer {API_KEY}

Response example

{
  "id": "usr-abc123",
  "email": "me@example.com",
  "name": "Jane Doe",
  "createdAt": "2023-01-15T10:00:00Z"
}

List teams for authenticated user

• Method: GET
• URL: https://api.render.com/v1/user/teams
• Watch out for: Returns only teams the API key owner belongs to.

Request example

GET /v1/user/teams
Authorization: Bearer {API_KEY}

Response example

[
  {
    "team": {"id": "tea-xyz", "name": "Acme Corp"},
    "role": "admin"
  }
]

• Rate limits: Render enforces rate limits on API requests but does not publicly document specific numeric thresholds per plan in their official docs as of the latest review.

• Rate-limit headers: Unknown

• Retry-After header: Unknown

• Rate-limit notes: No explicit rate limit values, headers, or Retry-After behavior documented in official Render API docs.

• Pagination method: cursor

• Default page size: 20

• Max page size: 100

• Pagination pointer: cursor

• Webhooks available: No

• Webhook notes: Render does not offer user-management or team-event webhooks via its public API as documented in official sources.

• Alternative event strategy: Use SCIM provisioning (Enterprise) for automated user lifecycle events via an IdP, or poll the team members endpoint.

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Enterprise

• Endpoint: https://api.render.com/scim/v2

• Supported operations: Create user (POST /Users), Read user (GET /Users/{id}), List users (GET /Users), Update user (PUT /Users/{id}), Deactivate user (PATCH /Users/{id} with active:false), Delete user (DELETE /Users/{id})

Limitations:

• Requires SSO to be configured before SCIM can be enabled.
• Supported IdPs: Okta and Microsoft Entra ID only (as of official docs).
• Google Workspace and OneLogin are not officially supported for SCIM.
• SCIM token is generated in the Render dashboard under Security settings; it is separate from the REST API key.
• Group/team provisioning support scope is not explicitly documented.

Three automation scenarios are well-supported by the current API surface.

Invite a new developer: POST /v1/teams/{teamId}/members with email and role. The member status remains pending until the invitation is accepted; poll GET /v1/teams/{teamId}/members filtered by email to confirm accepted before treating provisioning as complete.

SCIM provisioning via Okta or Entra ID (Enterprise only): Configure SSO first, generate a separate SCIM token under Security settings (distinct from the REST API key), and set the SCIM base URL to https://api.render.com/scim/v2.

Deprovisioning via the IdP sends PATCH active:false or DELETE; this is the preferred path for automated offboarding at Enterprise tier.

Remove a departed employee across teams: Enumerate teams via GET /v1/user/teams, resolve memberId per team via GET /v1/teams/{teamId}/members, then DELETE /v1/teams/{teamId}/members/{memberId} for each.

If the user is the sole owner of any team, deletion will fail - ownership must be transferred before removal.

Invite a new developer to a Render team

1. Obtain the teamId from GET /v1/user/teams.
2. POST /v1/teams/{teamId}/members with {"email":"dev@example.com","role":"member"}.
3. User receives an email invitation and must accept it.
4. Poll GET /v1/teams/{teamId}/members and filter by email to confirm status changes to 'accepted'.

Watch out for: The member will not have access until they accept the invitation; status remains 'pending' until then.

Automate user provisioning via SCIM with Okta (Enterprise)

1. Ensure SSO is configured in Render dashboard under Security > SSO.
2. Navigate to Security > SCIM and generate a SCIM token.
3. In Okta, add the Render SCIM app and configure the base URL as https://api.render.com/scim/v2 with Bearer token auth.
4. Assign users/groups in Okta; Okta will POST to /scim/v2/Users to provision accounts.
5. Deprovisioning in Okta sends a PATCH with active:false or DELETE to remove access.

Watch out for: SCIM token and REST API key are separate credentials; do not substitute one for the other.

Remove a departed employee from all teams

1. Call GET /v1/user/teams to enumerate all teams the admin manages.
2. For each teamId, call GET /v1/teams/{teamId}/members and find the memberId matching the user's email.
3. Call DELETE /v1/teams/{teamId}/members/{memberId} for each team.
4. If on Enterprise with SCIM, deprovisioning via the IdP is preferred and will handle this automatically.

Watch out for: If the user is the sole owner of a team, deletion will fail; ownership must be transferred first.

The most significant operational trap is token persistence after member removal: deleting a team member via the API or dashboard does not invalidate that user's personal API keys.

Any service or script using those keys retains access until the keys are explicitly revoked, which must be done by the key owner or through account-level action - not via the team member API.

A second trap applies to SCIM adopters: the SCIM token and the REST API key are separate credentials and are not interchangeable. Misconfiguring an IdP integration with the REST API key instead of the SCIM token is a documented failure mode.

Additionally, SCIM group/team provisioning scope is not explicitly documented by Render, so bulk group-to-team mapping behavior should be validated in a non-production environment before relying on it in an identity graph sync pipeline.

For teams building automated identity graph workflows, the absence of webhooks for user-management events means any real-time sync must rely on polling - there is no push notification when a member accepts an invitation or when a role changes.