Small Improvements User Management API Guide

Auth method: API Key (Bearer token passed in Authorization header)

Setup steps

1. Log in as an admin and navigate to Company Settings.
2. Locate the API section and generate an API key.
3. Include the key in all requests as: Authorization: Bearer

List users

• Method: GET
• URL: https://www.small-improvements.com/api/v1/users
• Watch out for: Exact query parameters and pagination behavior are not publicly documented.

Request example

GET /api/v1/users
Authorization: Bearer <api_key>

Response example

[{"id":"u1","email":"jane@example.com","firstName":"Jane","lastName":"Doe","active":true}]

Get user by ID

• Method: GET
• URL: https://www.small-improvements.com/api/v1/users/{userId}
• Watch out for: Field names and response schema are inferred from limited public information; verify against live API.

Request example

GET /api/v1/users/u1
Authorization: Bearer <api_key>

Response example

{"id":"u1","email":"jane@example.com","firstName":"Jane","lastName":"Doe"}

Create user

• Method: POST
• URL: https://www.small-improvements.com/api/v1/users
• Watch out for: Exact required fields not confirmed in public docs; test in a sandbox environment first.

Request example

POST /api/v1/users
Authorization: Bearer <api_key>
Content-Type: application/json
{"email":"new@example.com","firstName":"New","lastName":"User"}

Response example

{"id":"u2","email":"new@example.com","firstName":"New","lastName":"User","active":true}

Update user

• Method: PUT
• URL: https://www.small-improvements.com/api/v1/users/{userId}
• Watch out for: Whether PATCH is also supported is not confirmed in public documentation.

Request example

PUT /api/v1/users/u2
Authorization: Bearer <api_key>
Content-Type: application/json
{"department":"Engineering"}

Response example

{"id":"u2","email":"new@example.com","department":"Engineering"}

Deactivate/delete user

• Method: DELETE
• URL: https://www.small-improvements.com/api/v1/users/{userId}
• Watch out for: Behavior (soft deactivation vs. hard delete) is not explicitly documented publicly.

Request example

DELETE /api/v1/users/u2
Authorization: Bearer <api_key>

Response example

{"success":true}

• Rate limits: No rate-limit details are publicly documented.

• Rate-limit headers: No

• Retry-After header: No

• Rate-limit notes: No rate-limit details are publicly documented.

• Pagination method: offset

• Default page size: Not documented

• Max page size: Not documented

• Pagination pointer: Not documented

• Webhooks available: No

• Webhook notes: No webhook capability is documented in official Small Improvements public materials.

• Alternative event strategy: Poll the REST API periodically to detect user or data changes.

• SCIM available: No
• SCIM version: Not documented
• Plan required: Enterprise
• Endpoint: Not documented

Limitations:

• Native SCIM provisioning is not listed as a supported feature in official documentation.
• SSO via Okta, Azure AD/Entra, and OneLogin is supported, but automated user provisioning via SCIM is not confirmed.
• User lifecycle management must be handled via the REST API or manual admin actions.

Three integration patterns are supported by the available endpoints, each with meaningful caveats.

For bulk onboarding, POST to /api/v1/users per employee (email, firstName, lastName minimum);

no batch endpoint is documented, so each user requires an individual request - factor this into throughput planning.

For offboarding, retrieve the user's internal ID via GET /api/v1/users, then send DELETE or PUT with active:false to /api/v1/users/{userId};

because soft-deactivation vs.

hard-delete behavior is undocumented, test in a non-production environment before running in production.

For HRIS manager-hierarchy sync, fetch all users, map HRIS manager IDs to Small Improvements user IDs, then update each record via PUT /api/v1/users/{userId} with the correct managerId

managers must be created before direct reports or the update will fail.

Building an accurate identity graph across these three flows requires storing the returned Small Improvements user ID at creation time and maintaining a durable mapping to your HRIS or IdP identifiers.

Bulk-import new employees via REST API

1. Generate an API key from Company Settings > API.
2. For each new employee, POST to /api/v1/users with email, firstName, and lastName.
3. Store the returned user ID for future update or deactivation calls.

Watch out for: No bulk/batch endpoint is documented; each user requires an individual POST request.

Deactivate a departed employee

1. Retrieve the user's internal ID via GET /api/v1/users?email= or list endpoint.
2. Send DELETE (or PUT with active:false) to /api/v1/users/{userId}.
3. Confirm the account is inactive before removing from IdP.

Watch out for: Soft-deactivation vs. hard-delete behavior is undocumented; test in a non-production environment.

Sync manager hierarchy from HRIS

1. Fetch all users via GET /api/v1/users.
2. Map HRIS manager IDs to Small Improvements user IDs.
3. Update each user record with the correct managerId via PUT /api/v1/users/{userId}.

Watch out for: If managerId references a user not yet created in Small Improvements, the update may fail; ensure managers are created before direct reports.

The primary integration risk is documentation sparsity: field names, error codes, pagination behavior, and DELETE semantics are not publicly specified, meaning any production integration carries schema-drift risk that only live API testing can surface.

SCIM is not natively supported - IdP integrations with Okta, Entra, and OneLogin cover SSO only, not automated provisioning - so teams expecting IdP-driven lifecycle management will need to build that layer themselves via the REST API. The absence of webhooks means event-driven architectures are not possible;

polling introduces latency in offboarding flows, which is a security consideration for access revocation SLAs.

Teams using an MCP server with 60+ deep IT/identity integrations can abstract some of this complexity, but the underlying API gaps (undocumented rate limits, no batch endpoints, ambiguous delete behavior) remain constraints at the protocol level regardless of the orchestration layer.