Role-Based Access Control
Paycux enforces three kinds of access today: workspace roles on every console route, owner, admin and member roles inside each end-user organisation, and plan entitlements on usage events. Custom roles and permission definitions are planned and labelled as such below.
Available in part — Role-Based Access Control: Fixed workspace roles, organisation roles and plan entitlements are enforced today; custom roles, permission definitions and permission claims in tokens are not. Items listed as planned below cannot be enabled yet. What Paycux provides today.
Status
How it works today
Every member of your Paycux workspace holds one of five roles. The API reads the role from the session cookie on each request and refuses writes the role does not allow.
People who use your application create organisations and invite colleagues as member or admin. The caller's role gates who may invite, revoke and list.
Each usage event is checked against the account's plan entitlements and answered with an allow or deny decision that your application enforces.
Workspace roles
Roles are fixed: owner, admin, developer, billing and viewer. Owners and admins manage members, invites, projects and configuration; billing members manage the workspace plan; every role can read.
Organisation roles
An end user creates an organisation with a realm access token and becomes its owner. Owners and admins invite colleagues as member or admin; acceptance requires the same verified e-mail address as the invitation.
What is enforced today
Each item below is a route or a check in the Paycux API today. The item marked planned is on the roadmap and cannot be enabled from the console.
Requests
Console routes carry the dashboard session cookie. Organisation and usage routes carry the end user's realm access token.
1curl https://api.paycux.com/v1/auth/session \2 --cookie "__Host-paycux_session=<session cookie>"34HTTP 2005{6 "workspaceId": "3f9d2c1e-5b7a-4c8d-9e0f-1a2b3c4d5e6f",7 "actorId": "6d1f0b2e-3c4a-4d5e-8f60-7a8b9c0d1e2f",8 "role": "admin"9}
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. Workspace roles are fixed at owner, admin, developer, billing and viewer, and organisation roles at owner, admin and member. Custom roles and permission definitions are planned.
No. The dashboard session carries the workspace role, which the API reads on each request. End-user realm tokens carry identity only; the organisation role is looked up per request. Permission claims in tokens are planned.
Every dashboard session of that member is revoked in the same transaction as the removal, and the event is written to the workspace audit ledger.
An owner or admin creates an invite with role member or admin. The invitee accepts with a realm access token whose verified e-mail address matches the invitation; a mismatch fails closed.
Each usage event is checked against the billing account's plan. The response says whether it was allowed and why: WITHIN_LIMIT, LIMIT_EXCEEDED, NO_ENTITLEMENT or SEAT_REQUIRED.
Keep exploring
Create a workspace, invite your team with a role and let your end users manage their own organisations. Custom roles are planned and will be listed in the changelog when they are available.