Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.praxis-ai.com/llms.txt

Use this file to discover all available pages before exploring further.

Personal API keys let you authenticate non-interactive callers — scripts, SDKs, CI runners, notebooks — against Pria without baking a web-session JWT into your tooling. The key is your long-lived credential; you exchange it at runtime for a short-lived JWT and call the rest of the API with that JWT.
Personal API keys are an Admin-only capability. If you are demoted from Admin to User, any key you previously generated will stop working immediately — every sign-in attempt is re-checked against your current account type.

API key vs JWT — what’s the difference

When you sign in through the web app, Pria gives your browser a JSON Web Token (JWT) that expires after 24 hours. Calling the API directly with that JWT works, but it means re-authenticating every day and storing a value that rotates frequently. A personal API key is a stable, long-lived credential that identifies you to non-interactive callers. It is not itself a bearer token — it must be exchanged for a JWT via a single short request. Once exchanged, the JWT behaves exactly like the one your browser uses.
Personal API keys never leave the device they were generated on unless you move them yourself. Pria stores only a SHA-256 hash of the key — the raw value is shown to you exactly once at generation time.

Who can create a key

RoleCan generate a keyCan sign in with a key
AdminYesYes
UserNoNo
If you need API access but are not an Admin, ask the Admin of your Digital Twin to promote you, or contact the Praxis AI team at humans@praxis-ai.com to request access.

Generating a key

1

Open Your Profile

Click your profile icon in the top-right and select Your Profile.
2

Open the Developer tab

In Personal Settings, switch to the Developer tab. This tab is only visible to accounts with the Admin role.
3

Generate the key

Click Generate API key. Pria creates a fresh key and shows it to you in full, exactly once.
4

Copy and store it immediately

Use the copy button next to the displayed key and paste it into a password manager or secret store. Once you close or navigate away from this view, you cannot retrieve the key again — only its short prefix and creation date are stored.
The raw key is shown exactly once. If you lose it, you must rotate to a new one — there is no recovery flow.

Key format

Every key has the shape:
pria_<40 lowercase hex characters>
For example: pria_d350d4156bf1ba9b14332240c30b7c7941195ba6. The pria_ prefix makes keys easy to identify in code review and secret-scanning tools.

Using the key — the two-step exchange

Personal API keys are not bearer tokens. Calling a protected endpoint with the raw pria_… value in an Authorization: Bearer header returns:
{ "success": false, "message": "Invalid access token jwt malformed" }
Instead, you exchange the key for a JWT once per session via POST /api/auth/api-key-signin, sending the key in the x-api-key header. The response carries a JWT in .token that you then use for every subsequent call as Authorization: Bearer <jwt>.

Example — curl

APIKEY="pria_d350d4156bf1ba9b14332240c30b7c7941195ba6"

# Step 1 — exchange the API key for a short-lived JWT
JWT=$(curl -sS -X POST "https://pria.praxislxp.com/api/auth/api-key-signin" \
  -H "x-api-key: $APIKEY" \
  | python -c "import json,sys; print(json.load(sys.stdin)['token'])")

# Step 2 — call any protected endpoint with the JWT
curl -sS "https://pria.praxislxp.com/api/user/api-key" \
  -H "Authorization: Bearer $JWT"
The /api-key-signin endpoint is rate-limited (100 requests per minute per IP). For batch jobs, exchange the key once at startup and reuse the JWT across all subsequent calls instead of re-exchanging on every request.

Rotating and revoking keys

Rotate

Generating a new key when one already exists overwrites the old one — the previous key stops working immediately. Use rotation when a key may have been exposed in a log, a screenshot, or a former teammate’s machine. When you rotate, Pria also wipes the device usage history tied to the old key. The new key starts with a clean device list, and any caller still holding the old value will be told the key is invalid the next time they try to exchange it.

Revoke

Use Revoke API key to remove the key entirely without issuing a replacement. Revocation:
  • Hard-deletes the key hash, prefix, and creation timestamp from your profile.
  • Wipes all device usage rows for that key.
  • Records an apiKey.revoked audit entry tied to your account.
You can generate a new one later — there is no cooldown.
JWTs that were already minted from the old key continue to work until they expire (up to 24 hours). Revocation prevents new exchanges, not the use of an outstanding JWT. If you need to invalidate in-flight JWTs immediately, contact the Praxis AI team at humans@praxis-ai.com.

Device usage tracking

Every successful exchange records a row in your Recent device usage list. Pria identifies each device by a coarse fingerprint built from your /24 IP subnet, browser family, and operating system — enough to group repeat sign-ins from the same network and device, but not enough to identify you across different networks or different machines. For each device row you see:
  • Source IP and /24 subnet
  • Browser family, version, and operating system
  • Optional client name and hostname (if your tool advertises one via User-Agent)
  • First seen, last seen, and total sign-in count
Rows are listed most-recently-seen first, capped at 50. Each row expires 180 days after its last sign-in, so old, idle devices fall off automatically.
Spot an unfamiliar entry? Rotate your API key. Deleting a single device row is cosmetic — it only hides the row from your list and does not invalidate the device’s access. Real revocation always means rotating or revoking the key.

Security best practices

Add .env files (or whatever you use to load secrets) to .gitignore. Use a secret-scanning tool like gitleaks or trufflehog to catch accidental commits — the pria_ prefix makes keys easy to detect.
For CI runners and deployed services, store the key in a managed secret store (AWS Secrets Manager, HashiCorp Vault, GitHub Actions secrets, GitLab CI variables) rather than environment files on disk.
For service accounts, rotate every 90 days at minimum. For human Admin accounts, rotate any time you change machines, leave a team, or suspect exposure.
Re-exchanging on every request will hit the rate limiter on busy workloads and unnecessarily expand the device-usage log. Cache the JWT in memory for the duration of the job.
The Recent device usage list is your tripwire. Check it after any rotation, after onboarding a new tool, and any time you suspect a credential leak.