Directory Provisioning
How Directory Provisioning works in Paycux, what it is for, and the smallest setup that gets it running.
Introduction
Directory Provisioning is part of the Paycux platform. This page explains what it does, when to reach for it, and the smallest working setup you can ship.
Everything below applies to both environments. Build and test in staging, then promote the same configuration to production without changing your code — only the API key and client ID differ.
Initial configuration
Initial configuration is handled by Directory Provisioning rather than by your application code. Paycux exposes it through the same API surface as the rest of the platform, so the client you already configured needs no additional setup.
Configuration lives in the dashboard and is versioned per environment. Change it in staging, confirm the behaviour, then apply the same change to production.
Supported directory providers
Directory Sync keeps your user list in step with the customer's directory. Paycux receives create, update and delete operations and normalizes them into a single shape regardless of the source system.
Deletes arrive as deactivations. Treat a deactivated user as a user who can no longer sign in, and decide separately whether to delete their data.
Provision users from a directory
A user record holds the identity Paycux resolved for the person: email, name, verification state, and the identities they have linked. It is the object your application should key on.
Users are unique by email within a project. When the same person arrives through a second provider, Paycux links the identity to the existing user rather than creating a duplicate.
Manage users from a directory
Manage users from a directory applies specifically to Directory Provisioning. It behaves the same in both environments, and the values it depends on are visible in the dashboard for the environment you have selected.
If the behaviour you see does not match this description, check which environment your API key belongs to before anything else — a staging key against production data is the most common cause.
Custom attributes
Paycux normalizes incoming attributes into a fixed profile shape, so your application reads the same fields no matter which provider the user came from.
| Paycux field | Typical source |
|---|---|
| NameID, email, or mail | |
| first_name | givenName or first_name |
| last_name | surname, sn, or last_name |
| idp_id | The provider's stable user identifier |
Anything the provider sends beyond these fields is kept verbatim under raw_attributes, so you can map custom claims without waiting on us.
Directory provisioning actions
Directory provisioning actions applies specifically to Directory Provisioning. It behaves the same in both environments, and the values it depends on are visible in the dashboard for the environment you have selected.
If the behaviour you see does not match this description, check which environment your API key belongs to before anything else — a staging key against production data is the most common cause.
Frequently asked questions
Frequently asked questions is handled by Directory Provisioning rather than by your application code. Paycux exposes it through the same API surface as the rest of the platform, so the client you already configured needs no additional setup.
Configuration lives in the dashboard and is versioned per environment. Change it in staging, confirm the behaviour, then apply the same change to production.