Modern Treasury User Management API Guide

Auth method: HTTP Basic Auth (API key as username, empty password; or Organization ID + API key pair)

Setup steps

1. Log in to the Modern Treasury dashboard.
2. Navigate to Settings → API Keys.
3. Create a new API key; note the Organization ID shown in the same settings area.
4. Encode 'organization_id:api_key' in Base64 and pass as the Authorization header: 'Authorization: Basic '.
5. All requests must be made over HTTPS.

List Users

• Method: GET
• URL: https://app.moderntreasury.com/api/users
• Watch out for: Pagination uses cursor-based after_cursor/before_cursor params, not page numbers.

Request example

GET /api/users?per_page=25 HTTP/1.1
Host: app.moderntreasury.com
Authorization: Basic <base64(org_id:api_key)>

Response example

{
  "object": "list",
  "items": [{"id": "usr_abc123", "object": "user", "email": "alice@example.com", "name": "Alice"}],
  "after_cursor": "cursor_xyz",
  "per_page": 25
}

Get User

• Method: GET
• URL: https://app.moderntreasury.com/api/users/{id}
• Watch out for: Returns 404 if the user ID does not belong to the authenticated organization.

Request example

GET /api/users/usr_abc123 HTTP/1.1
Host: app.moderntreasury.com
Authorization: Basic <base64(org_id:api_key)>

Response example

{
  "id": "usr_abc123",
  "object": "user",
  "email": "alice@example.com",
  "name": "Alice",
  "created_at": "2024-01-15T10:00:00Z"
}

• Rate limits: Modern Treasury enforces rate limits per API key. The official docs note limits exist but do not publish specific numeric thresholds publicly.
• Rate-limit headers: Unknown
• Retry-After header: Unknown
• Rate-limit notes: Contact Modern Treasury support for specific rate limit figures. HTTP 429 is returned when limits are exceeded.
• Pagination method: cursor
• Default page size: 25
• Max page size: 1000
• Pagination pointer: after_cursor / before_cursor

• Webhooks available: Yes
• Webhook notes: Modern Treasury supports webhooks for event-driven notifications. Webhook endpoints are configured in the dashboard under Settings → Webhooks.
• Alternative event strategy: User-specific lifecycle events (e.g., user provisioned/deprovisioned) are handled via SCIM rather than webhooks.
• Webhook events: payment_order.created, payment_order.updated, transaction.created, transaction.updated, internal_account.updated, counterparty.created, counterparty.updated

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Enterprise

• Endpoint: https://app.moderntreasury.com/scim/v2

• Supported operations: Create User (POST /Users), Get User (GET /Users/{id}), List Users (GET /Users), Update User (PUT /Users/{id}), Deactivate User (PATCH /Users/{id} with active=false), Get Groups (GET /Groups), Create Group (POST /Groups), Update Group (PATCH /Groups/{id})

Limitations:

• Requires Enterprise plan.
• SCIM token is generated from the Modern Treasury dashboard under Settings → SCIM.
• IdP-specific connector configuration (Okta, Entra ID, etc.) must be set up on the IdP side using the SCIM base URL and bearer token.
• Group push support may vary by IdP connector; verify with Modern Treasury support.

For identity graph construction, the audit scenario is the primary REST API use case: authenticate with Basic Auth, call GET /api/users?per_page=1000, and paginate using after_cursor until the field returns null.

Each user object surfaces id, email, name, role, created_at, updated_at, and live_mode - sufficient to join against an identity graph across your SaaS fleet.

For provisioning, the SCIM path is the only supported write mechanism.

Configure your IdP (Okta, Entra ID, etc.) with the SCIM base URL and a bearer token generated from Settings → SCIM.

The IdP then manages POST /scim/v2/Users on hire and PATCH /scim/v2/Users/{id} with active=false on departure.

SCIM token rotation requires IdP connector reconfiguration - plan for a maintenance window.

Deprovisioning via SCIM deactivates the user but may not immediately revoke active API sessions;

confirm session invalidation behavior directly with Modern Treasury support.

Webhooks are available for payment and transaction events but do not emit user lifecycle events.

User provisioning and deprovisioning signals must come from SCIM, not webhooks.

Audit all users in an organization

1. Authenticate using Basic Auth with Organization ID and API key.
2. GET /api/users?per_page=1000 to retrieve the first page of users.
3. Check the after_cursor field in the response; if present, repeat with ?after_cursor= until after_cursor is null.
4. Aggregate all user objects for audit logging.

Watch out for: Max per_page is 1000; large organizations may require multiple paginated requests.

Provision a new employee via SCIM (Enterprise)

1. Ensure the organization is on the Enterprise plan.
2. In the Modern Treasury dashboard, navigate to Settings → SCIM and generate a SCIM token.
3. Configure your IdP (e.g., Okta) with SCIM base URL https://app.moderntreasury.com/scim/v2 and the bearer token.
4. Assign the user to the Modern Treasury application in the IdP; the IdP will POST /scim/v2/Users with the user's profile.
5. Modern Treasury creates the user and returns a SCIM User object with the assigned id.

Watch out for: SCIM token rotation requires reconfiguring the IdP connector; plan for downtime or use a maintenance window.

Deactivate a departed employee via SCIM

1. In the IdP, remove or deactivate the user's assignment to the Modern Treasury application.
2. The IdP sends a PATCH /scim/v2/Users/{id} request with {"Operations": [{"op": "replace", "path": "active", "value": false}]}.
3. Modern Treasury deactivates the user, revoking their access.
4. Verify deactivation by calling GET /api/users/{id} and confirming the user's status.

Watch out for: Deprovisioning via SCIM deactivates the user but may not immediately revoke active API sessions; confirm behavior with Modern Treasury support.

The most significant integration caveat is the hard dependency on the Enterprise plan for any write-path user management via SCIM. Teams on lower tiers have no API-based provisioning option and must fall back to manual dashboard operations. Rate limit thresholds are not publicly documented;

HTTP 429 is the only signal of exhaustion, and numeric limits must be obtained directly from Modern Treasury support - build in retry logic with exponential backoff from the start.

For teams building an identity graph with 60+ deep IT/identity integrations via an MCP server, the read-only REST API provides enough signal for access visibility, but automated lifecycle management requires confirming Enterprise plan status before committing to an API-driven architecture.