Sprout Social User Management API Guide

Auth method: OAuth 2.0 (Bearer token)

Setup steps

1. Register an application in the Sprout Social Developer portal to obtain a client_id and client_secret.
2. Direct the user to the Sprout Social OAuth 2.0 authorization endpoint to obtain an authorization code.
3. Exchange the authorization code for an access token via POST to the token endpoint.
4. Include the access token as a Bearer token in the Authorization header of all API requests.

Required scopes

Get authenticated user (self)

• Method: GET
• URL: https://api.sproutsocial.com/v1/me
• Watch out for: Returns data for the token owner only; not a full user-list endpoint.

Request example

GET /v1/me
Authorization: Bearer {access_token}

Response example

{
  "data": {
    "id": 123456,
    "email": "user@example.com",
    "name": "Jane Doe",
    "role": "Admin"
  }
}

List team members

• Method: GET
• URL: https://api.sproutsocial.com/v1/{customer_id}/team/members
• Watch out for: Requires Admin-level token. Pagination via cursor parameter.

Request example

GET /v1/12345/team/members
Authorization: Bearer {access_token}

Response example

{
  "data": [
    {"id": 1, "name": "Jane Doe", "email": "jane@example.com", "role": "Admin"}
  ]
}

Get team member

• Method: GET
• URL: https://api.sproutsocial.com/v1/{customer_id}/team/members/{member_id}
• Watch out for: Returns a single user object; member_id is the Sprout-internal integer ID.

Request example

GET /v1/12345/team/members/67890
Authorization: Bearer {access_token}

Response example

{
  "data": {
    "id": 67890,
    "name": "John Smith",
    "email": "john@example.com",
    "role": "Member"
  }
}

Invite / create team member

• Method: POST
• URL: https://api.sproutsocial.com/v1/{customer_id}/team/members
• Watch out for: Sends an invitation email; user is not active until they accept. Availability of this endpoint via public API vs. SCIM only is not fully documented.

Request example

POST /v1/12345/team/members
Content-Type: application/json

{"email":"new@example.com","name":"New User","role":"Member"}

Response example

{
  "data": {
    "id": 99001,
    "email": "new@example.com",
    "role": "Member"
  }
}

Update team member

• Method: PATCH
• URL: https://api.sproutsocial.com/v1/{customer_id}/team/members/{member_id}
• Watch out for: Only fields included in the request body are updated.

Request example

PATCH /v1/12345/team/members/67890
Content-Type: application/json

{"role":"Manager"}

Response example

{
  "data": {
    "id": 67890,
    "role": "Manager"
  }
}

Remove team member

• Method: DELETE
• URL: https://api.sproutsocial.com/v1/{customer_id}/team/members/{member_id}
• Watch out for: Permanently removes the user from the account. For Enterprise SCIM-managed users, prefer SCIM deactivation to avoid sync conflicts.

Request example

DELETE /v1/12345/team/members/67890
Authorization: Bearer {access_token}

Response example

HTTP 204 No Content

• Rate limits: Sprout Social enforces per-customer rate limits on the public API. The official docs note a default limit but do not publish per-plan tier breakdowns publicly.
• Rate-limit headers: Unknown
• Retry-After header: Unknown
• Rate-limit notes: Official docs do not explicitly document rate-limit response headers or Retry-After behavior. Treat as unknown.
• Pagination method: cursor
• Default page size: 0
• Max page size: 0
• Pagination pointer: cursor

• Webhooks available: No
• Webhook notes: Sprout Social's public API documentation does not describe a webhook system for user-management events (user created, deactivated, role changed). No such events are documented.
• Alternative event strategy: Poll the team members list endpoint periodically, or use SCIM provisioning (Enterprise) for push-based lifecycle events from your IdP.

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Enterprise

• Endpoint: Tenant-specific SCIM base URL provided by Sprout Social during SSO/SCIM setup (not a generic public endpoint; obtained from the Sprout Social admin settings or IdP app configuration).

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

Limitations:

• SSO must be configured and active before SCIM provisioning can be enabled.
• Supported IdPs are Okta and Microsoft Entra ID (Azure AD); Google Workspace and OneLogin are not officially supported.
• SCIM endpoint URL is tenant-specific and not publicly documented; must be retrieved from Sprout Social admin settings.
• Group/team provisioning support via SCIM is not explicitly documented in public help articles.
• Enterprise plan required; not available on Standard, Professional, or Advanced plans.

Three primary automation scenarios are supported by the available API surface:

• Okta SCIM provisioning (Enterprise): SSO must be fully active before SCIM is enabled. The SCIM base URL and bearer token are tenant-specific and retrieved from the Sprout Social admin panel - there is no static public endpoint. Deprovisioning sends PATCH /Users/{id} with active:false; it does not hard-delete the user record.

• Team member audit via REST: GET /v1/{customer_id}/team/members with cursor-based pagination. Iterate until no next cursor is returned. Rate limit thresholds are not publicly documented; implement exponential backoff. Token must be Admin-scoped.

• Role update via REST: PATCH /v1/{customer_id}/team/members/{member_id} with the target role in the request body. If the user is SCIM-managed, the same attribute must be updated in the IdP to prevent the next sync from reverting the change.

Automated user provisioning via Okta SCIM (Enterprise)

1. Confirm the Sprout Social account is on the Enterprise plan.
2. Configure SSO in Sprout Social admin settings (Okta SAML app) and verify SSO is working.
3. In Sprout Social admin settings, enable SCIM and copy the tenant-specific SCIM base URL and bearer token.
4. In Okta, add the Sprout Social SCIM app, paste the SCIM base URL and token, and configure attribute mappings (email, name, role).
5. Assign Okta users/groups to the Sprout Social app; Okta will POST to /Users to create accounts.
6. Deprovisioning: unassign the user in Okta; Okta sends PATCH /Users/{id} with active:false to deactivate.

Watch out for: SSO must be active before SCIM is enabled. Disabling SSO after enabling SCIM may break provisioning sync.

List and audit all team members via REST API

1. Obtain an OAuth 2.0 access token with Admin privileges.
2. GET https://api.sproutsocial.com/v1/{customer_id}/team/members
3. Iterate through paginated results using the cursor parameter until no next cursor is returned.
4. Compare returned user list against your directory to identify orphaned or misconfigured accounts.

Watch out for: Token must belong to an Admin user; non-admin tokens will receive a 403. Rate limits are undocumented - add delays between paginated requests.

Update a user's role via REST API

1. Obtain the target user's Sprout Social member_id from the list endpoint.
2. PATCH https://api.sproutsocial.com/v1/{customer_id}/team/members/{member_id} with body {"role": "Manager"}.
3. Verify the response returns the updated role field.
4. If the user is SCIM-managed, also update the role attribute in the IdP to prevent drift on next sync.

Watch out for: Manually updating a SCIM-managed user's role via REST API may be overwritten on the next SCIM sync from the IdP.

The primary integration trap is conflating the REST API's team endpoints with a full provisioning solution. The invite endpoint (POST /v1/{customer_id}/team/members) sends an invitation email - the user is not active until they accept, meaning automated provisioning flows cannot confirm activation without a follow-up GET.

The endpoint's availability via the public REST API versus SCIM-only paths is not fully documented.

A second trap is the undocumented rate limit surface. No per-plan thresholds, rate-limit response headers, or Retry-After behavior are publicly specified. Treat all limits as unknown and build retry logic defensively from the start.

Finally, SCIM requires SSO to be active first - disabling SSO after enabling SCIM breaks provisioning sync with no automatic fallback. Google Workspace and OneLogin are not officially supported IdPs; only Okta and Microsoft Entra ID are documented.