Receiving users (SCIM server)
Twine acts as a SCIM server. Customer identity providers act as SCIM clients and push user lifecycle operations - create, update, deactivate, and delete - to Twine’s SCIM endpoints. Each operation is mapped into Twine’s Employee data model and stored on the Organization. This is the most common SCIM setup. It works with any standards-compliant SCIM client.Authentication
For inbound SCIM, Twine generates a dedicated role in the customer’s Organization with a long-lived request token attached to it. The token is presented as a bearer credential by the SCIM client on every request. This is a different mechanism from the refresh-token flow used by Twine’s public API.Token rotation details are still being finalised and will be documented here.
Pushing users (bulk upload to Entra)
Twine can also act as a SCIM client and push users in bulk to a customer’s identity provider via the inbound provisioning API. This is currently supported for Microsoft Entra. Support for additional identity providers (Okta and others) may be added in the future. The Entra inbound provisioning flow is documented at Configure Microsoft Entra ID inbound provisioning.Authentication
Entra inbound provisioning uses certificate-based authentication. Twine generates the certificate and exposes the public key to the customer, who configures it on the Entra application. No client IDs or client secrets are involved, and the customer never handles the private key. The flow described in the linked Microsoft article is provided for context only - Twine does not use the client-secret-based path it describes.Supported domains
| Domain | Inbound | Outbound |
|---|---|---|
| Employee | Yes | Yes (Entra only) |