Spendesk User Management API Guide

Auth method: Not documented

User object field mapping is not yet verified for this app.

Endpoint coverage is not yet verified for this app.

• Rate limits: Not documented

• Rate-limit headers: No

• Retry-After header: No

• Rate-limit notes: Not documented

• Pagination method: none

• Default page size: 0

• Max page size: 0

• Pagination pointer: Not documented

• Webhooks available: No

• Webhook notes: No publicly documented webhook system for user-management events found in official Spendesk documentation.

• Alternative event strategy: Manual user management via the Spendesk web application; SSO-based JIT (Just-In-Time) provisioning via SAML 2.0 with supported IdPs (Okta, Entra ID, OneLogin) is the closest automated alternative.

• SCIM available: No
• SCIM version: Not documented
• Plan required: Enterprise (Custom pricing)
• Endpoint: Not documented

Limitations:

• SCIM provisioning is not listed as available in official Spendesk help documentation or supported IdP integration catalogs as of research date.
• SSO (SAML 2.0) is available as a paid add-on or included in certain plans; SCIM is separate and not confirmed available.
• User provisioning must be performed manually through the Spendesk admin UI or via IdP-driven JIT provisioning through SAML SSO.

The only partially automatable scenario is onboarding via SAML SSO with JIT provisioning.

When a user is assigned to the Spendesk application in the IdP and authenticates for the first time, a Spendesk account is created automatically.

However, role assignment, team membership, and spending limits are not carried over from the IdP and require a follow-up manual step in the Spendesk admin console.

Offboarding has no automation path.

Revoking IdP access removes SSO login ability but does not deactivate the Spendesk account.

Manual deactivation via Settings → Members is always required, and pending approvals plus open cards must be resolved separately.

Bulk user management has no public API or SCIM endpoint.

There is no programmatic option for batch creates, updates, or deactivations.

Any bulk operation requires either manual UI work or a custom enterprise arrangement negotiated directly with Spendesk.

Onboard a new employee via SSO

1. Configure SAML 2.0 SSO in Spendesk admin settings using your IdP (Okta, Entra ID, or OneLogin).
2. Assign the user to the Spendesk application in your IdP.
3. User authenticates via IdP; JIT provisioning creates a Spendesk account on first login if enabled.
4. Admin manually assigns the user to the correct team and spending policy within Spendesk.

Watch out for: JIT provisioning via SAML does not automatically assign roles, teams, or spending limits; manual configuration in Spendesk is still required post-login.

Offboard a departing employee

1. Revoke the user's access to Spendesk in your IdP (removes SSO login ability).
2. Manually deactivate or remove the user account in the Spendesk admin console.
3. Reassign any pending approvals or open requests to another user before deactivation.

Watch out for: Without SCIM, IdP deprovisioning does not automatically deactivate the Spendesk account; manual deactivation in Spendesk is required to fully remove access.

Bulk user management

1. No public API or SCIM endpoint is available for bulk operations.
2. Use the Spendesk admin UI to manage users individually or in bulk via CSV import if supported.
3. Contact Spendesk enterprise support to inquire about private API or bulk provisioning options under a custom agreement.

Watch out for: No programmatic bulk user management is publicly documented; all automation options are limited to IdP SSO/JIT flows.

The core trap is assuming that SSO coverage equals lifecycle coverage. SAML JIT provisioning handles first-login account creation, but it does not write roles, does not sync group membership to teams or budgets, and does not trigger deactivation on IdP removal. Each gap requires a manual intervention that is easy to miss at scale.

For teams maintaining an identity graph, Spendesk accounts will drift from IdP state over time without a dedicated audit process. There is no webhook system for user-management events, no SCIM endpoint to poll, and no read API to reconcile against.

The only reliable source of truth for current Spendesk user state is the admin console itself. Custom enterprise agreements may unlock undocumented integration capabilities, but nothing in public documentation confirms this.