Integrations

Enterprise SSO (planned)

Nothing on this page can be executed today. Paycux has no per-organisation SAML or OIDC connection, no metadata import, no domain routing and no test tooling. The samples below are the foundation routes that do exist: realm setup and organisation membership.

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

Before you begin

Nothing to prepare for SSO itself; it cannot be enabled.
If you want the foundation in place: an environment whose Authentication tab shows ready, and an application that completes the authorization code flow against its realm.
An organisation model in your application that can map to Paycux organisations, which end users create through the API today.

Install

There is nothing to install. Paycux is a plain HTTPS JSON API, so every example on this page uses curl. Console routes send the dashboard session cookie, end-user routes send the application's realm access token as a bearer credential, and agent routes send the short-lived agent token. The routes that exist today are listed on What exists today.

terminal

1# Console routes carry the dashboard session cookie set by sign-in
2curl https://api.paycux.com/v1/auth/session \
3  -H "Cookie: __Host-paycux_session=<session>"
4 
5# End-user routes carry the application's realm access token
6curl https://api.paycux.com/v1/<end-user route> \
7  -H "Authorization: Bearer <realm access token>"

Configure

There are no SSO configuration values. The values below are the identity configuration an application holds today.

.env.local

1PAYCUX_API_BASE_URL=https://api.paycux.com
2PAYCUX_PROJECT_ID=<project id>
3PAYCUX_ENVIRONMENT_ID=<environment id>
4PAYCUX_REALM_ID=<realm id>
5PAYCUX_OIDC_ISSUER=<issuer shown in the console>
6PAYCUX_OIDC_CLIENT_ID=<client id shown in the console>

Then, in the dashboard:

1There is no SSO or connection section in the console today.
2The Authentication tab shows the environment's realm: status, issuer, client ID, realm ID and the registered redirect and logout URLs.
3The Organisations tab lists the organisations end users created, with their active members and pending invites; owners and admins can revoke a pending invite.

Implement

The planned flow: an organisation would register its identity provider from metadata; a verified e-mail domain would route sign-in to that connection; assertions would be verified against the stored certificate, rotated when the provider rotates it; IdP-initiated flows would be refused or bound to a known request; a test tool would confirm the connection before activation. No route implements any of this. The samples show only what exists.

Foundation: read the realm setup

This read exists today and returns the realm a connection would attach to. There is no connection or identity provider field in the response.

terminal

1curl "https://api.paycux.com/v1/environments/<environment id>/auth?projectId=<project id>" \
2  --cookie "__Host-paycux_session=<session cookie>"
3 
4HTTP 200
5{
6  "setup": {
7    "realmId": "<realm id>",
8    "displayName": "Example App",
9    "redirectUris": ["https://app.example.com/auth/callback"],
10    "logoutRedirectUris": ["https://app.example.com/"],
11    "status": "ready",
12    "issuer": "https://<identity host>/realms/pcx-<uuid>",
13    "clientId": "<client id>",
14    "discoveryUrl": "https://<identity host>/realms/pcx-<uuid>/.well-known/openid-configuration",
15    "lastErrorCode": null
16  }
17}
18# The full object also carries workspaceId, projectId, environmentId,
19# providerRealmName, checkoutReturnUrls, revision and appliedRevision.

Foundation: create an organisation and invite a member

End-user routes that exist today, using the realm access token. The invite token is returned once and stored only as a hash; acceptance requires the invited address to be the accepting user's verified e-mail.

terminal

1curl --request POST "https://api.paycux.com/v1/billing/organizations" \
2  --header "Authorization: Bearer <realm access token>" \
3  --header "Content-Type: application/json" \
4  --data '{"projectId":"<project id>","environmentId":"<environment id>","realmId":"<realm id>","displayName":"Example Ltd"}'
5 
6HTTP 201
7{ "billingAccountId": "<billing account id>", "kind": "organization", "role": "owner" }
8 
9curl --request POST "https://api.paycux.com/v1/billing/organizations/<billing account id>/invites" \
10  --header "Authorization: Bearer <realm access token>" \
11  --header "Content-Type: application/json" \
12  --data '{"projectId":"<project id>","environmentId":"<environment id>","realmId":"<realm id>","email":"grace@example.com","role":"admin"}'
13 
14HTTP 201
15{ "inviteId": "<invite id>", "token": "<invite token, shown once>", "role": "admin", "expiresAt": "2026-10-20T09:12:44.000Z" }

Foundation: organisation members

Any active member can list members; owners and admins also receive pending invites with masked e-mail addresses. This is the membership a planned connection would map onto.

terminal

1curl "https://api.paycux.com/v1/billing/organizations/<billing account id>/members?projectId=<project id>&environmentId=<environment id>&realmId=<realm id>" \
2  --header "Authorization: Bearer <realm access token>"
3 
4HTTP 200
5{
6  "billingAccountId": "<billing account id>",
7  "role": "owner",
8  "members": [
9    {
10      "identityId": "<identity id>",
11      "role": "owner",
12      "status": "active",
13      "joinedAt": "2026-10-13T09:12:44.000Z"
14    }
15  ],
16  "invites": [
17    {
18      "inviteId": "<invite id>",
19      "email": "g***@example.com",
20      "role": "admin",
21      "expiresAt": "2026-10-20T09:12:44.000Z"
22    }
23  ]
24}

Verify

There is nothing to verify for SSO. You can confirm the foundation.

1Confirm the environment's Authentication tab shows ready.
2Create an organisation with a realm access token and confirm it appears on the environment's Organisations tab.
3Invite a second address, accept with that user's realm access token, and confirm the member is listed with its role.

What exists todayThe implemented API, with no SSO route.

Reference

Request and response shapes for each of these live in the API reference. Paths are relative to https://api.paycux.com.

Method	Path	What it does
GET	/v1/environments/:environmentId/auth?projectId=	Foundation: realm setup, issuer and registered URLs. Dashboard session cookie.
POST	/v1/billing/organizations	Foundation: an end user creates an organisation. Bearer token.
POST	/v1/billing/organizations/:billingAccountId/invites	Foundation: invite an e-mail address as member or admin. Bearer token; owner or admin of the organisation.
POST	/v1/billing/invites/accept	Foundation: accept with the token; the caller's verified e-mail must match.
GET	/v1/billing/organizations/:billingAccountId/members?projectId=&environmentId=&realmId=	Foundation: members and, for owners and admins, pending invites.
GET	/v1/environments/:environmentId/organizations?projectId=	Foundation: operator view of the organisations in an environment. Dashboard session cookie.

Next steps

User Management integrationThe realm, screens, identities and organisations that exist today.Organization Setup integrationOrganisations and invites as they work today.Enterprise SSO overviewPlanned scope and the foundation that exists.What exists todayEvery implemented route.

Integrations

Enterprise SSO (planned)

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

Before you begin

Nothing to prepare for SSO itself; it cannot be enabled.
If you want the foundation in place: an environment whose Authentication tab shows ready, and an application that completes the authorization code flow against its realm.
An organisation model in your application that can map to Paycux organisations, which end users create through the API today.

Install

terminal

1# Console routes carry the dashboard session cookie set by sign-in
2curl https://api.paycux.com/v1/auth/session \
3  -H "Cookie: __Host-paycux_session=<session>"
4 
5# End-user routes carry the application's realm access token
6curl https://api.paycux.com/v1/<end-user route> \
7  -H "Authorization: Bearer <realm access token>"

Configure

There are no SSO configuration values. The values below are the identity configuration an application holds today.

.env.local

1PAYCUX_API_BASE_URL=https://api.paycux.com
2PAYCUX_PROJECT_ID=<project id>
3PAYCUX_ENVIRONMENT_ID=<environment id>
4PAYCUX_REALM_ID=<realm id>
5PAYCUX_OIDC_ISSUER=<issuer shown in the console>
6PAYCUX_OIDC_CLIENT_ID=<client id shown in the console>

Then, in the dashboard:

1There is no SSO or connection section in the console today.
2The Authentication tab shows the environment's realm: status, issuer, client ID, realm ID and the registered redirect and logout URLs.
3The Organisations tab lists the organisations end users created, with their active members and pending invites; owners and admins can revoke a pending invite.

Implement

Foundation: read the realm setup

This read exists today and returns the realm a connection would attach to. There is no connection or identity provider field in the response.

terminal

1curl "https://api.paycux.com/v1/environments/<environment id>/auth?projectId=<project id>" \
2  --cookie "__Host-paycux_session=<session cookie>"
3 
4HTTP 200
5{
6  "setup": {
7    "realmId": "<realm id>",
8    "displayName": "Example App",
9    "redirectUris": ["https://app.example.com/auth/callback"],
10    "logoutRedirectUris": ["https://app.example.com/"],
11    "status": "ready",
12    "issuer": "https://<identity host>/realms/pcx-<uuid>",
13    "clientId": "<client id>",
14    "discoveryUrl": "https://<identity host>/realms/pcx-<uuid>/.well-known/openid-configuration",
15    "lastErrorCode": null
16  }
17}
18# The full object also carries workspaceId, projectId, environmentId,
19# providerRealmName, checkoutReturnUrls, revision and appliedRevision.

Foundation: create an organisation and invite a member

terminal

1curl --request POST "https://api.paycux.com/v1/billing/organizations" \
2  --header "Authorization: Bearer <realm access token>" \
3  --header "Content-Type: application/json" \
4  --data '{"projectId":"<project id>","environmentId":"<environment id>","realmId":"<realm id>","displayName":"Example Ltd"}'
5 
6HTTP 201
7{ "billingAccountId": "<billing account id>", "kind": "organization", "role": "owner" }
8 
9curl --request POST "https://api.paycux.com/v1/billing/organizations/<billing account id>/invites" \
10  --header "Authorization: Bearer <realm access token>" \
11  --header "Content-Type: application/json" \
12  --data '{"projectId":"<project id>","environmentId":"<environment id>","realmId":"<realm id>","email":"grace@example.com","role":"admin"}'
13 
14HTTP 201
15{ "inviteId": "<invite id>", "token": "<invite token, shown once>", "role": "admin", "expiresAt": "2026-10-20T09:12:44.000Z" }

Foundation: organisation members

Any active member can list members; owners and admins also receive pending invites with masked e-mail addresses. This is the membership a planned connection would map onto.

terminal

1curl "https://api.paycux.com/v1/billing/organizations/<billing account id>/members?projectId=<project id>&environmentId=<environment id>&realmId=<realm id>" \
2  --header "Authorization: Bearer <realm access token>"
3 
4HTTP 200
5{
6  "billingAccountId": "<billing account id>",
7  "role": "owner",
8  "members": [
9    {
10      "identityId": "<identity id>",
11      "role": "owner",
12      "status": "active",
13      "joinedAt": "2026-10-13T09:12:44.000Z"
14    }
15  ],
16  "invites": [
17    {
18      "inviteId": "<invite id>",
19      "email": "g***@example.com",
20      "role": "admin",
21      "expiresAt": "2026-10-20T09:12:44.000Z"
22    }
23  ]
24}

Verify

There is nothing to verify for SSO. You can confirm the foundation.

1Confirm the environment's Authentication tab shows ready.
2Create an organisation with a realm access token and confirm it appears on the environment's Organisations tab.
3Invite a second address, accept with that user's realm access token, and confirm the member is listed with its role.

What exists todayThe implemented API, with no SSO route.

Reference

Request and response shapes for each of these live in the API reference. Paths are relative to https://api.paycux.com.

Method	Path	What it does
GET	/v1/environments/:environmentId/auth?projectId=	Foundation: realm setup, issuer and registered URLs. Dashboard session cookie.
POST	/v1/billing/organizations	Foundation: an end user creates an organisation. Bearer token.
POST	/v1/billing/organizations/:billingAccountId/invites	Foundation: invite an e-mail address as member or admin. Bearer token; owner or admin of the organisation.
POST	/v1/billing/invites/accept	Foundation: accept with the token; the caller's verified e-mail must match.
GET	/v1/billing/organizations/:billingAccountId/members?projectId=&environmentId=&realmId=	Foundation: members and, for owners and admins, pending invites.
GET	/v1/environments/:environmentId/organizations?projectId=	Foundation: operator view of the organisations in an environment. Dashboard session cookie.