Front User Management API Guide

Auth method: Bearer token (API token issued per company or per teammate)

Setup steps

1. Log in to Front and navigate to Settings > Developers > API Tokens.
2. Create a new API token scoped to the desired permissions (company-level tokens have broader access).
3. Store the token securely; it is shown only once.
4. Include the token in all requests as the Authorization header: 'Authorization: Bearer '.

Required scopes

List teammates

• Method: GET
• URL: https://api2.frontapp.com/teammates
• Watch out for: Returns all teammates including blocked ones; filter client-side on is_blocked if needed.

Request example

GET /teammates?limit=50 HTTP/1.1
Authorization: Bearer <token>
Accept: application/json

Response example

{
  "_pagination": {"next": "https://api2.frontapp.com/teammates?page_token=abc"},
  "_results": [
    {"id":"tea_123","email":"alice@example.com","first_name":"Alice","is_admin":false}
  ]
}

Get teammate

• Method: GET
• URL: https://api2.frontapp.com/teammates/{teammate_id}
• Watch out for: Use the teammate's id (tea_xxx), not email, as the path parameter.

Request example

GET /teammates/tea_123 HTTP/1.1
Authorization: Bearer <token>

Response example

{
  "id": "tea_123",
  "email": "alice@example.com",
  "first_name": "Alice",
  "last_name": "Smith",
  "is_admin": false,
  "is_available": true
}

Create teammate

• Method: POST
• URL: https://api2.frontapp.com/teammates
• Watch out for: An invitation email is sent to the new teammate automatically upon creation.

Request example

POST /teammates HTTP/1.1
Authorization: Bearer <token>
Content-Type: application/json

{"email":"bob@example.com","first_name":"Bob","is_admin":false}

Response example

{
  "id": "tea_456",
  "email": "bob@example.com",
  "first_name": "Bob",
  "is_admin": false
}

Update teammate

• Method: PATCH
• URL: https://api2.frontapp.com/teammates/{teammate_id}
• Watch out for: Returns 204 with no body on success. Only include fields you want to change.

Request example

PATCH /teammates/tea_456 HTTP/1.1
Authorization: Bearer <token>
Content-Type: application/json

{"is_admin":true,"is_available":false}

Response example

HTTP 204 No Content

Delete (deactivate) teammate

• Method: DELETE
• URL: https://api2.frontapp.com/teammates/{teammate_id}
• Watch out for: Deleting a teammate deactivates them; historical data is retained. This cannot be undone via API.

Request example

DELETE /teammates/tea_456 HTTP/1.1
Authorization: Bearer <token>

Response example

HTTP 204 No Content

List teams

• Method: GET
• URL: https://api2.frontapp.com/teams
• Watch out for: Teams in Front correspond to inbox groups, not organizational units.

Request example

GET /teams HTTP/1.1
Authorization: Bearer <token>

Response example

{
  "_results": [
    {"id":"tim_1","name":"Support","is_private":false}
  ]
}

Add teammates to team

• Method: POST
• URL: https://api2.frontapp.com/teams/{team_id}/teammates
• Watch out for: Accepts an array of teammate IDs; adding an already-member teammate is a no-op.

Request example

POST /teams/tim_1/teammates HTTP/1.1
Authorization: Bearer <token>
Content-Type: application/json

{"teammate_ids":["tea_123","tea_456"]}

Response example

HTTP 204 No Content

Remove teammates from team

• Method: DELETE
• URL: https://api2.frontapp.com/teams/{team_id}/teammates
• Watch out for: Body is required even for DELETE; omitting teammate_ids will result in a 400 error.

Request example

DELETE /teams/tim_1/teammates HTTP/1.1
Authorization: Bearer <token>
Content-Type: application/json

{"teammate_ids":["tea_456"]}

Response example

HTTP 204 No Content

• Rate limits: Front enforces per-token rate limits. The default limit is 120 requests per minute for most endpoints. Limits are communicated via response headers.
• Rate-limit headers: Yes
• Retry-After header: Yes
• Rate-limit notes: Headers returned: X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset. When limit is exceeded, Front returns HTTP 429. Retry after the value in the Retry-After header.
• Pagination method: cursor
• Default page size: 50
• Max page size: 100
• Pagination pointer: page_token

• Webhooks available: Yes
• Webhook notes: Front supports webhooks for real-time event notifications. Webhooks are configured per channel or at the company level via the Front settings UI or API. They deliver HTTP POST payloads to a configured URL.
• Alternative event strategy: Poll GET /teammates on a schedule if webhooks are not feasible.
• Webhook events: conversation.created, conversation.assigned, conversation.unassigned, conversation.archived, conversation.reopened, message.received, message.sent, teammate.created, teammate.updated, teammate.deleted

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Professional (Growth) or above; Enterprise for full IdP integration with Okta/Entra

• Endpoint: https://api2.frontapp.com/scim/v2

• Supported operations: Create user (POST /Users), Delete/deactivate user (DELETE /Users/{id}), List users (GET /Users)

Limitations:

• Currently only supports creation and deletion of teammates via SCIM; update (PATCH /Users) support is limited
• Group (team) provisioning via SCIM is not documented as supported
• SSO must be configured as a prerequisite for SCIM provisioning
• Supported IdPs: Okta, Microsoft Entra ID (Azure AD); Google Workspace and OneLogin not officially supported

Three scenarios cover the core lifecycle. To provision a new teammate: POST /teammates with email, first_name, last_name, and is_admin=false, capture the returned tea_xxx ID, then POST to /teams/{team_id}/teammates with {"teammate_ids":["tea_xxx"]} to assign team membership.

POST /teammates always triggers an invitation email - there is no silent provisioning path through the REST API; use SCIM if suppressing the invite is required by your IdP flow.

To deactivate a departed teammate: GET /teammates to resolve the ID by email, DELETE /teammates/{teammate_id}, then confirm with GET and assert is_blocked=true; reactivation cannot be done via API and must be completed in the Front UI. For bulk lifecycle management, the SCIM 2.

0 endpoint (https://api2.frontapp.com/scim/v2) integrates with Okta and Microsoft Entra ID but currently supports only create and delete - PATCH /Users for attribute updates has limited support, and group/team provisioning via SCIM is not documented.

Building a complete identity graph across Front requires combining REST API teammate records with team membership data from /teams/{team_id}/teammates, since SCIM does not expose team-level membership state.

Provision a new teammate and assign to a team

1. POST /teammates with email, first_name, last_name, is_admin=false to create the user.
2. Capture the returned teammate id (tea_xxx) from the response.
3. POST /teams/{team_id}/teammates with body {"teammate_ids":["tea_xxx"]} to add to the desired team.
4. Verify membership with GET /teams/{team_id}/teammates.

Watch out for: Step 1 sends an invitation email automatically. The teammate must accept before they can log in, but the API record is created immediately.

Deactivate a departed teammate

1. GET /teammates to find the teammate's id by email.
2. DELETE /teammates/{teammate_id} to deactivate the account.
3. Confirm deactivation by GET /teammates/{teammate_id} and checking is_blocked=true.

Watch out for: Deletion via API is irreversible through the API; reactivation must be done manually in the Front UI. Historical conversations are preserved.

Bulk-sync users via SCIM with Okta

1. Ensure SSO (SAML) is configured and active in Front Settings > Security.
2. In Front Settings > Security > SCIM, generate a SCIM API token.
3. In Okta, add the Front SCIM app and configure the SCIM base URL (https://api2.frontapp.com/scim/v2) and Bearer token.
4. Map Okta user attributes to Front SCIM attributes (userName → email, name.givenName, name.familyName).
5. Assign users/groups in Okta to trigger provisioning; Front will create or deactivate teammates automatically.

Watch out for: SCIM in Front currently supports create and delete only. Attribute updates (e.g., name changes) pushed from Okta may not sync to existing Front teammate records.

The primary API trap is assuming SCIM provides full IdP parity. It does not: attribute changes pushed from Okta or Entra (such as name updates or department changes) may not propagate to existing Front teammate records, leaving your identity graph stale for any field beyond provisioning state.

A second trap is the DELETE endpoint's irreversibility via API - reactivation requires a manual UI action, which breaks fully automated offboarding pipelines.

Finally, the SCIM base URL may be tenant-specific; do not hardcode https://api2.frontapp.com/scim/v2 without confirming the exact value in Front Settings → Security → SCIM, as mismatches produce auth failures that are difficult to distinguish from token errors.