Loading page
Sign-in UI
Each environment's identity realm serves registration, e-mail verification, sign-in, password reset and logout screens. Your application starts a standard authorization code flow and never handles a password. Branding, passwordless and social sign-in are planned.
Available in part — Sign-in UI: Hosted screens exist on every provisioned realm and the Paycux dashboard signs its own members in the same way; branding controls, passwordless, social providers, localisation and embedded widgets are planned. Items listed as planned below cannot be enabled yet. What Paycux provides today.
Status
Flow
Build the authorization URL from the discovery document with the console's client ID, a registered redirect URL and a PKCE challenge. The realm renders the sign-in screen with a registration link.
New users register and must verify their e-mail before a token is accepted. Existing users sign in with e-mail and password, or use the forgot-password link.
Your callback exchanges the code with the PKCE verifier. No client secret exists, and the access token is what you present to the Paycux API.
Boundaries
The hosted screens are the realm's own pages. They work on every ready realm and are isolated per environment, but there are no customer-facing branding controls yet.
Security
The client the realm provisions is deliberately narrow, so a misconfigured application cannot widen it.
Screens
All of these exist on every ready realm today. Styling and additional sign-in methods are planned.
HTTP
Everything your application needs is in the console and the realm's discovery document. There is no SDK.
1curl "https://api.paycux.com/v1/environments/<environment id>/auth?projectId=<project id>" \2 --cookie "__Host-paycux_session=<session cookie>"34HTTP 2005{6 "setup": {7 "displayName": "Example App",8 "redirectUris": ["https://app.example.com/auth/callback"],9 "logoutRedirectUris": ["https://app.example.com/"],10 "status": "ready",11 "issuer": "https://<identity host>/realms/pcx-<uuid>",12 "clientId": "<client id>",13 "discoveryUrl": "https://<identity host>/realms/pcx-<uuid>/.well-known/openid-configuration",14 "realmId": "<realm id>",15 "lastErrorCode": null16 }17}18# The full object also carries workspaceId, projectId, environmentId,19# providerRealmName, checkoutReturnUrls, revision and appliedRevision.
Transparent pricing
In part No separate price for what works today.Workspace plans
Included in every workspace plan. Limits (projects, provider connections, members, usage events) are listed on the pricing page.
Questions
Not yet. There are no branding settings in the console or the API today. Logo, colours, theme and custom domains are planned.
No. The screens are hosted by the realm and reached by redirect. Embedded widgets are planned.
E-mail and password only, with mandatory e-mail verification and password reset. Magic links, passwordless and social providers are planned.
Yes, in environments named development or preview: http loopback redirect and logout URLs are accepted there. Every other environment requires exact HTTPS URLs.
From the realm's own e-mail delivery, which the Paycux operator configures. Until it is configured the environment's setup stays failed and no user can verify an account.
The dashboard signs its members in through a realm of the same kind, with the same registration, verification and reset screens. Customer realms are separate and isolated per environment.
Keep exploring
Create a workspace, configure an environment's Authentication tab and start the authorization code flow against the issuer it reports.