Directory Provisioning

Automatic user and group provisioning, planned

Paycux does not provision users from a customer's directory yet. The foundations exist: identities per realm, organisations with members and invites, and an audit ledger. SCIM 2.0 endpoints, group mapping and deprovisioning are planned.

What exists today Read the planned scope

Directory ProvisioningPlanned

Roadmap preview

1Not available yet

2Planned

3Planned

Not available yet — Directory Provisioning is a planned capability. It is not part of Paycux today and cannot be enabled from the console. What Paycux provides today.

This preview is not a currently available API contract.

Status

What exists today, and what is planned

Works today

PlannedPlanned

PlannedSCIM 2.0 users and groups endpoints with a bearer token per organisation
PlannedGroup-to-role mapping onto organisation roles
PlannedIdempotent provisioning and deprovisioning
PlannedRetry and reconciliation of failed deliveries
PlannedCross-tenant isolation tests before release

Planned flow

How the planned flow would work

Connect a directory

An organisation would receive a SCIM 2.0 endpoint and its own bearer token to configure in the customer's identity provider.

Provision and update

User and group changes would create, update or deactivate memberships idempotently, with directory groups mapped onto organisation roles.

Deprovision and reconcile

A removal would revoke the membership. Failed deliveries would be retried and reconciled, with every change in the audit ledger.

What exists today

The records a directory would write into

Provisioning is a writer on top of records Paycux already keeps. None of the writer exists yet; the records do, and you can fill them through invites now.

Identities per realm, created on first use from a verified realm access token
Organisations with owner, admin and member roles, invites and revocation
Masked member and invite views for your team in the console
A hash-chained audit ledger that membership changes already append to

What exists todayPlanned

Roadmap preview

1Not available yet

2Planned

3Planned

Planned

What has to ship before this is available

The planned scope is listed so you can judge the gap, not so you can depend on it. Nothing here can be enabled from the console.

SCIM 2.0 Users and Groups resources and per-organisation bearer tokens
Group-to-role mapping, idempotent create and update, deprovisioning that revokes access
Retry, reconciliation and delivery evidence
Cross-tenant isolation tests and a reviewed release

PlannedPlanned

Roadmap preview

1Not available yet

2Planned

3Planned

Planned scope

What Directory Provisioning would cover

Every item below is planned. The foundation items at the top of the page are the only parts available now.

SCIM 2.0 endpointsUsers and Groups resources per organisation, authenticated with a bearer token issued for that organisation.

Group-to-role mappingDirectory groups mapped onto organisation roles, so a group change becomes a role change.

Idempotent provisioningRepeated create or update calls converge on one membership instead of duplicating it.

DeprovisioningA removal in the directory revokes the membership and the access that came with it.

Retry and reconciliationFailed deliveries retried, and the directory state reconciled against Paycux records.

Isolation evidenceCross-tenant isolation tests and a reviewed release before the planned label is removed.

Foundation routes

What you can call today

There is no provisioning endpoint. These are the organisation routes that exist now; a planned directory connection would write to the same memberships.

1curl -X POST https://api.paycux.com/v1/billing/organizations \
2  -H "Authorization: Bearer <realm access token>" \
3  -H "Content-Type: application/json" \
4  -d '{
5    "projectId": "a1000000-0000-4000-8000-000000000002",
6    "environmentId": "a1000000-0000-4000-8000-000000000003",
7    "realmId": "a1000000-0000-4000-8000-000000000004",
8    "displayName": "Example Robotics"
9  }'
10 
11HTTP 201
12{
13  "billingAccountId": "c2b1a0f9-8e7d-4c6b-9a5f-4e3d2c1b0a99",
14  "kind": "organization",
15  "role": "owner"
16}

Questions

Frequently asked

Can I connect a SCIM directory today?

No. There are no SCIM endpoints, directory tokens or group mappings in the API. Memberships are created through invites that end users accept.

What can I build on now?

The organisations API: create organisations, invite members with a role, accept with a verified e-mail address and list members. Those are the records provisioning would write to.

Will directory groups map onto roles?

That is the plan: directory groups onto organisation roles. The mapping model is not final and may change before release.

How will I know when it is available?

The planned label is removed only after the API and console exist, isolation tests pass and the release is reviewed. The changelog records it.

Keep exploring

The rest of the platform

User ManagementIn partPer-environment customer identity; account administration planned

Enterprise SSOPlannedUnified SSO for any identity provider

Abuse ChecksIn partRate limiting exists today; risk decisions planned

Sign-in UIIn partHosted sign-in screens exist; branding controls planned

Role-Based Access ControlIn partWorkspace and organisation roles exist; custom permissions planned

Agent AccessIn partScoped agent tokens exist; delegated consent planned

Build on what exists

Use the organisations API for memberships today and follow the changelog for Directory Provisioning.

Get started Talk to an expert

The records a directory would write into

Provisioning is a writer on top of records Paycux already keeps. None of the writer exists yet; the records do, and you can fill them through invites now.

Identities per realm, created on first use from a verified realm access token

Organisations with owner, admin and member roles, invites and revocation

Masked member and invite views for your team in the console

A hash-chained audit ledger that membership changes already append to

What has to ship before this is available

The planned scope is listed so you can judge the gap, not so you can depend on it. Nothing here can be enabled from the console.

SCIM 2.0 Users and Groups resources and per-organisation bearer tokens

Group-to-role mapping, idempotent create and update, deprovisioning that revokes access

Retry, reconciliation and delivery evidence

Cross-tenant isolation tests and a reviewed release

1curl -X POST https://api.paycux.com/v1/billing/organizations \

2 -H "Authorization: Bearer <realm access token>" \

3 -H "Content-Type: application/json" \

4 -d '{

5 "projectId": "a1000000-0000-4000-8000-000000000002",

6 "environmentId": "a1000000-0000-4000-8000-000000000003",

7 "realmId": "a1000000-0000-4000-8000-000000000004",

8 "displayName": "Example Robotics"

9 }'

11HTTP 201

12{

13 "billingAccountId": "c2b1a0f9-8e7d-4c6b-9a5f-4e3d2c1b0a99",

14 "kind": "organization",

15 "role": "owner"

16}