Personal API Keys

This page is for administrators who want to connect their own software to Pria. If you only use Pria in the browser, you don’t need an API key. A personal API key lets a program — a script, an automated job, a notebook — sign in to Pria as you, without you having to copy a browser sign-in token into it by hand. The key is your long-lived credential; at run time the program exchanges it for a short-lived sign-in token (a JWT) and calls the rest of the API with that.

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 a few hours (six by default). Calling the API directly with that JWT works, but it means re-authenticating several times a 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

Role	Can generate a key	Can sign in with a key
Admin	Yes	Yes
User	No	No

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

Open Your Profile

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

Open the Developer / API tab

In your profile settings, switch to the Developer / API tab (Studio UI: Settings › API). This tab is only visible to accounts with the Admin role.

Generate the key

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

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_0123456789abcdef0123456789abcdef01234567. 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_0123456789abcdef0123456789abcdef01234567"

# 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

Clicking Regenerate 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 to remove the key entirely without issuing a replacement. Revocation:

Removes the key from your profile entirely (Pria never stored the raw value in the first place).
Wipes all device usage rows for that key.
Records an 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 a few 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 or client family, version, and operating system
Optional client name and hostname — your tool can identify itself by sending the x-pria-client-name and x-pria-client-hostname headers with the sign-in request
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. The Forget device action on a 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.

Restricting where the key works — Authorized sources

Below the device list, the Authorized sources section lets you limit where your key can be exchanged for a token. An empty list means the key works from anywhere (the default). You can add up to 20 entries of two kinds:

Server addresses — an IP address (203.0.113.7) or an IP range in CIDR form (203.0.113.0/24). Use these to pin the key to your servers, CI runners, or office network.
Web addresses — an origin like https://app.example.com (or a wildcard such as *.example.com). Use these to restrict browser-based use.

A request is allowed if it matches any entry on the list.

Build the list first, enforce later

Save your entries with Enforce this list switched off. In this warn-only mode nothing is blocked — Pria records sign-ins that would have been blocked, so you can confirm the list is complete before locking anything out.

Use the device list as your source of truth

Each row in Recent device usage shows the source it signed in from, with an Allow this source shortcut that adds it to the list, and a green authorized badge once it is on it.

Turn on enforcement

Once every legitimate source shows as authorized, enable Enforce this list and click Save sources. Sign-ins from anywhere else are rejected from that point on.

Most integrations connect from servers, not browsers — a list containing only web addresses will block them. Also note that mixing web addresses with server addresses weakens the server restriction (non-browser software can imitate a web address), so for a strict server lock keep the list to IP entries only. The panel warns you in both situations.

Security best practices

Never commit keys to source control

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.

Use a secret manager for deployed services

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.

Rotate on schedule

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.

Exchange once, reuse the JWT

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.

Watch the device list

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.

Digital Twin Capabilities

Files

Assistants

Memory

Settings & Account

API key vs JWT — what’s the difference

Who can create a key

Generating a key

Key format

Using the key — the two-step exchange

Example — curl

Rotating and revoking keys

Rotate

Revoke

Device usage tracking

Restricting where the key works — Authorized sources

Security best practices

​API key vs JWT — what’s the difference

​Who can create a key

​Generating a key

​Key format

​Using the key — the two-step exchange

​Example — curl

​Rotating and revoking keys

​Rotate

​Revoke

​Device usage tracking

​Restricting where the key works — Authorized sources

​Security best practices

​Related

API key vs JWT — what’s the difference

Who can create a key

Generating a key

Key format

Using the key — the two-step exchange

Example — curl

Rotating and revoking keys

Rotate

Revoke

Device usage tracking

Restricting where the key works — Authorized sources

Security best practices

Related