SCIM Provisioning

SCIM 2.0 keeps a FoPost workspace in step with your directory. Assign someone to the FoPost app in your identity provider and they become a member of the workspace; unassign them and their access goes away on the next sync, without anyone sending an invite.

Provisioning sits on top of single sign-on. Set up SSO for the workspace first and verify its email domain, because the verified domain is what decides whose accounts your directory is allowed to create.

Turn it on

1. Open the workspace settings in the dashboard and go to Sign-On.
2. Under Directory Provisioning, select Create Provisioning Token.
3. Copy the token. It is shown once and cannot be read again. If you lose it, rotate it and update your identity provider with the new one.
4. Copy the SCIM base URL shown next to it.

In your identity provider, create a SCIM 2.0 integration with:

The token belongs to one workspace and reaches nothing else. It is not an API key: revoking it never affects the keys your team uses for the REST API, and an API key can never be used against the SCIM endpoints.

What is supported

Listing supports filter=userName eq "[email protected]" and the startIndex and count parameters. Group provisioning is not available yet and answers 501.

The endpoints only ever show and change the members your directory created, plus anyone it later claims by pushing the same address. People invited by hand, including guests from other companies, are invisible to SCIM and cannot be changed through it. Manage those in Team.

Responses use application/scim+json. The id of a user is stable for as long as the person exists, so it is safe to store as the link between your directory and FoPost.

What each operation does

Create. A new member joins the workspace with the member role. If the person already has a FoPost account on that address, the existing account is reused rather than duplicated, and an existing membership on that address is taken over by the directory rather than refused. Roles are managed in FoPost, not pushed from the directory, so promoting someone to admin is done in Team.

Update. A display name change is applied. An address change is applied only when both the old and the new address are on the verified domain; anything else is refused with 400 so the mismatch shows up in your provisioning log instead of failing quietly.

Deactivate. Setting active to false, or sending DELETE, removes the person's access to the workspace and ends their signed-in sessions within a minute.

Deactivation never deletes content. Posts, scheduled work, media, and connected accounts belong to the workspace, not to whoever created them, so they stay exactly where they are when someone leaves. To erase a person's own account, use account deletion in Security.

Errors

Errors follow the SCIM error format.

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
  "status": "400",
  "scimType": "invalidValue",
  "detail": "userName must be an address on the domain this connection verified"
}