Authentication
The real mechanism, for every surface.
PaxExact's external API now authenticates with its own Bearer key scheme — everything else here describes what the platform does for the portal and admin console, including private-label operators who deploy their own instance.
PaxExact: a bearer API key (pxk)
The one product with a real external API today authenticates every request with a Bearer key shaped pxk_<env>_<key_id>_<secret> — sandbox keys are self-service through the API Center, live keys require an approved production request. The secret is shown once, at issue or rotation, and never stored or shown again. (A sandbox key's wire token reads pxk_test_… — "test" is that token segment's own name, while "sandbox" is what this platform calls the environment.) See the PaxExact API page for the full scheme.
Everything else: session cookie, not an API key
No other product has an external API-key scheme today. Every portal/admin request is authenticated by a signed session cookie issued at sign-in — the same mechanism the portal and admin console use.
Password storage
Credentials are hashed with scrypt and stored as <saltHex>:<hashHex>. The local password path is the development/self-hosted credential flow; production is expected to federate to an external identity provider rather than store passwords directly.
Permission-based authorization
Every privileged action is named as an explicit permission (for example, approving a deployment) and checked server-side against a default-deny grant table, keyed by role. Navigation never enforces this by itself — every page and change independently re-checks its own permission.
CSRF
Mutations require a double-submit CSRF token bound to the session, verified in the same call that checks the session and the permission — no form submission can accidentally skip one of the three.
Looking for endpoints, scopes, and request/response shapes? PaxExact API or the full developer guide.