Coralogix User Management API Guide

Auth method: API Key (Bearer token) - a Coralogix 'Teams API Key' or 'Personal API Key' passed as Authorization: Bearer

Setup steps

1. Log in to Coralogix and navigate to Settings → API Keys.
2. Create a 'Teams API Key' with the required scopes (e.g., 'User Management') for programmatic access, or use a 'Personal API Key' for user-scoped operations.
3. Copy the generated key; it is shown only once.
4. Pass the key in every request header: Authorization: Bearer .
5. For SCIM provisioning, generate a dedicated SCIM token under Settings → SCIM and use it as the Bearer token in your IdP connector.

Required scopes

List Users (SCIM)

• Method: GET
• URL: https://<cluster>.coralogix.com/scim/Users
• Watch out for: The cluster subdomain varies by region (e.g., coralogix.com, eu2.coralogix.com, coralogixsg.com). Use the correct regional endpoint.

Request example

GET /scim/Users
Authorization: Bearer <scim_token>
Accept: application/scim+json

Response example

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

Get User by ID (SCIM)

• Method: GET
• URL: https://<cluster>.coralogix.com/scim/Users/{id}
• Watch out for: Returns 404 if the user ID does not exist in the team.

Request example

GET /scim/Users/u1
Authorization: Bearer <scim_token>

Response example

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "id": "u1",
  "userName": "alice@example.com",
  "active": true
}

Create User (SCIM)

• Method: POST
• URL: https://<cluster>.coralogix.com/scim/Users
• Watch out for: An invitation email may be sent to the new user. Duplicate userName returns a 409 Conflict.

Request example

POST /scim/Users
Authorization: Bearer <scim_token>
Content-Type: application/scim+json

{"schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],"userName":"bob@example.com","active":true}

Response example

{
  "id": "u2",
  "userName": "bob@example.com",
  "active": true,
  "meta": {"created": "2024-01-10T10:00:00Z"}
}

Update User (SCIM PATCH)

• Method: PATCH
• URL: https://<cluster>.coralogix.com/scim/Users/{id}
• Watch out for: PATCH is the preferred update method; PUT (full replace) support should be verified against current docs.

Request example

PATCH /scim/Users/u2
Authorization: Bearer <scim_token>
Content-Type: application/scim+json

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

Response example

{
  "id": "u2",
  "userName": "bob@example.com",
  "active": false
}

Delete User (SCIM)

• Method: DELETE
• URL: https://<cluster>.coralogix.com/scim/Users/{id}
• Watch out for: Deletion is permanent. Consider deactivating (active=false) instead of deleting to preserve audit history.

Request example

DELETE /scim/Users/u2
Authorization: Bearer <scim_token>

Response example

HTTP 204 No Content

List Groups (SCIM)

• Method: GET
• URL: https://<cluster>.coralogix.com/scim/Groups
• Watch out for: Groups map to Coralogix teams/roles; group membership changes may affect user permissions immediately.

Request example

GET /scim/Groups
Authorization: Bearer <scim_token>

Response example

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
  "totalResults": 1,
  "Resources": [{"id":"g1","displayName":"Admins"}]
}

Create Group (SCIM)

• Method: POST
• URL: https://<cluster>.coralogix.com/scim/Groups
• Watch out for: Group names must be unique within the team.

Request example

POST /scim/Groups
Authorization: Bearer <scim_token>
Content-Type: application/scim+json

{"schemas":["urn:ietf:params:scim:schemas:core:2.0:Group"],"displayName":"Developers","members":[]}

Response example

{
  "id": "g2",
  "displayName": "Developers",
  "members": []
}

Filter Users (SCIM)

• Method: GET
• URL: https://<cluster>.coralogix.com/scim/Users?filter=userName+eq+%22alice@example.com%22
• Watch out for: Only a subset of SCIM filter operators may be supported; test filter expressions before relying on them in production.

Request example

GET /scim/Users?filter=userName+eq+%22alice@example.com%22
Authorization: Bearer <scim_token>

Response example

{
  "totalResults": 1,
  "Resources": [{"id":"u1","userName":"alice@example.com"}]
}

• Rate limits: Coralogix does not publicly document specific rate-limit thresholds for the user-management or SCIM APIs in official docs as of the research date.

• Rate-limit headers: No

• Retry-After header: No

• Rate-limit notes: No rate-limit headers or Retry-After behavior documented officially. Contact Coralogix support for current limits.

• Pagination method: none

• Default page size: 0

• Max page size: 0

• Pagination pointer: Not documented

• Webhooks available: No

• Webhook notes: Coralogix does not document outbound webhooks for user-management events (user created, deactivated, etc.) in official docs.

• Alternative event strategy: Poll SCIM /Users endpoint or use IdP-side event logs (e.g., Okta System Log) to track provisioning activity.

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Business (custom pricing); SSO must be configured as a prerequisite

• Endpoint: https://.coralogix.com/scim

• Supported operations: GET /Users, GET /Users/{id}, POST /Users, PATCH /Users/{id}, DELETE /Users/{id}, GET /Groups, POST /Groups, PATCH /Groups/{id}, DELETE /Groups/{id}

Limitations:

• SSO (SAML) must be enabled before SCIM provisioning can be activated.
• SCIM token is generated separately from standard API keys under Settings → SCIM.
• Regional cluster URL must match the account's data residency region.
• PUT (full replace) for Users is not explicitly confirmed in official docs; use PATCH.
• Pagination parameters (startIndex, count) support level is not explicitly documented.
• Plan gate: Business tier or above required per context data; confirm with Coralogix sales for current entitlements.

Three primary automation scenarios are supported by the SCIM surface.

First, new-employee provisioning: configure your IdP SCIM connector with the correct regional base URL and SCIM Bearer token, then assign the user to the Coralogix app in the IdP

a POST /scim/Users with userName (email), name fields, and active=true creates the account.

Second, deactivating a departing employee: filter by userName to retrieve the SCIM ID, then PATCH /scim/Users/{id} with active=false;

this blocks login but preserves the user record and historical data - DELETE is a separate, permanent call.

Third, bulk user auditing: GET /scim/Users returns a ListResponse with a Resources array;

pagination via startIndex and count parameters is not explicitly confirmed in official docs, so test behavior at your user volume before relying on it in production pipelines.

Provision a new employee via SCIM from an IdP

1. Ensure SSO (SAML) is configured in Coralogix Settings → SSO.
2. Generate a SCIM token in Coralogix Settings → SCIM.
3. Configure your IdP (e.g., Okta, Azure AD) SCIM connector with base URL https://.coralogix.com/scim and the SCIM token as Bearer auth.
4. Assign the user to the Coralogix application in the IdP.
5. IdP sends POST /scim/Users with userName (email), name, and active=true.
6. Verify the user appears in Coralogix Settings → Users.

Watch out for: If the regional cluster URL is wrong, the IdP will receive 401 or connection errors. Double-check the cluster domain before configuring the connector.

Deactivate a departing employee

1. Retrieve the user's SCIM ID: GET /scim/Users?filter=userName+eq+"user@example.com".
2. Send PATCH /scim/Users/{id} with Operations: [{op: replace, path: active, value: false}].
3. Confirm the response shows active: false.
4. Optionally, remove the user from all SCIM Groups via PATCH /scim/Groups/{groupId}.

Watch out for: Deactivation prevents login but does not remove the user record or their historical data. Use DELETE only if full removal is required.

Bulk-list all users for an audit

1. Send GET /scim/Users with Authorization: Bearer .
2. Parse the Resources array from the ListResponse.
3. Check totalResults; if it exceeds the returned count, attempt GET /scim/Users?startIndex=1&count=100 (pagination support unconfirmed - test first).
4. Export id, userName, active, and roles fields for the audit report.

Watch out for: Pagination behavior (startIndex/count) is not explicitly documented; the full user list may be returned in a single response for small teams, but behavior at scale is unconfirmed.

Several non-obvious failure modes exist. Role assignment via SCIM is not fully documented for standard attributes - group-to-role mapping must be configured in the IdP connector, and custom schema extensions may be required; do not assume the roles array behaves identically to other SCIM implementations.

PUT (full replace) for user objects is unconfirmed; use PATCH exclusively. Rate-limit thresholds are not publicly documented and no Retry-After headers are returned, so back-off logic must be implemented defensively without a documented ceiling to target.

No official SDK exists; all integrations require raw HTTP calls. Finally, removing a user from one SCIM group does not affect their membership or role in other Coralogix teams - group membership changes are scoped and can silently leave access intact elsewhere in the identity graph.