DocsAPI key
Authentication / 01

Get your Jev API key.

From a new TokenRa account to a verified request in a few minutes. This guide covers the full key lifecycle: create it, keep it out of source control, verify it, and rotate it without downtime.

01 account 02 environment 03 verify 04 rotate
01 / Create

Get a key from TokenRa

Jev is available through TokenRa's API gateway. Create an account, open the console, and create a key with a label that tells you where it will be used.

01

Create or sign in to your account

Start at TokenRa. Use a work email or the account you already use for API access.

Open TokenRa ↗
02

Open the API console

From the dashboard, go to the API key or account settings area. Keep billing and usage visibility enabled for the key's workload.

Open console ↗
03

Create and label the key

Choose a descriptive label such as jev-prod-api or jev-local-dev. Copy the secret immediately; providers commonly show it only once.

View Jev access ↗
Good defaultUse separate keys for local development, staging, and production. It makes a leak smaller and a revocation less disruptive.
02 / Configure

Put the key in your environment

The SDKs and examples can read TYPESAFE_API_KEY. Environment variables keep secrets separate from application code and make the same build portable across environments.

macOS / Linux / CI shell
export TYPESAFE_API_KEY="sk-your-tokenra-key"

Local development

Keep a .env.local file on your machine and add it to .gitignore.

TYPESAFE_API_KEY=sk_...

Production

Set the variable in your host's secret manager or runtime configuration, not in the image.

TYPESAFE_API_KEY=sk_...

CI / preview builds

Store it as an encrypted repository or organization secret and scope it to the needed jobs.

TYPESAFE_API_KEY=sk_...

Node.js access

Read the value at runtime. Do not prefix it with a public-browser variable such as NEXT_PUBLIC_.

process.env.TYPESAFE_API_KEY
Keep it server-sideAny value bundled into frontend JavaScript can be copied by every visitor. Call Jev from your server, edge function, or other protected backend.
03 / Verify

Send a safe first request

Verify the credential with a small, non-sensitive decision before wiring it into production traffic. The endpoint expects a Bearer token and a JSON request body.

POSThttps://tokenra.io/v1/decisions
curl / first request
curl https://tokenra.io/v1/decisions \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "jev-latest",
    "state": "A customer asks where to find an invoice.",
    "questions": {
      "intent": {
        "type": "choice",
        "instructions": "What does the customer need?",
        "criteria": {
          "billing": "Invoice or payment help",
          "technical": "A bug or integration issue"
        }
      }
    }
  }'

Expected shape

answers.intent.choice = "billing"   /   answers.intent.confidence = 0.91

A 401 response usually means the key is missing, malformed, expired, or not being read by the process. A 4xx response with a valid authorization header usually points to the request body or account configuration; check the full API docs next.

04 / Operate

Rotate keys without downtime

Treat a key like a deployable credential, not a permanent password. The overlap window below lets you move traffic before revoking the old secret.

Issue the replacement

Create a new key with a new label, such as jev-prod-2026-09. Do not overwrite the old secret yet.

Deploy and verify

Update the secret store, restart the service if needed, and send a canary request. Confirm usage moves to the new key.

Revoke the old key

After the replacement is healthy, disable the old key and record the rotation date in your runbook.

Do

  • Rotate on a documented schedule.
  • Revoke immediately after exposure.
  • Keep an owner and environment in the label.

Avoid

  • Deleting the old key before deployment.
  • Sharing one secret across every service.
  • Logging authorization headers or full request env.
05 / Secure

Security checklist

A few small controls prevent the most common API key incidents. Add these checks to code review and deployment setup.

Never commit secrets

Use .gitignore, secret scanning, and a pre-commit check. If a key appears in git history, treat it as exposed.

Keep logs clean

Redact Authorization headers and avoid dumping the complete process environment in error reports.

Limit the blast radius

Separate keys by environment and service where possible. Give each owner a clear revocation path.

Assume exposure is real

If a key lands in a public issue, chat, screenshot, or client bundle, revoke it first and investigate second.

06 / Answers

Frequently asked questions

Where do I get a Jev API key?

Create or sign in to a TokenRa account, open the console, and create an API key. The Jev model page is a useful starting point for access and model details.

Which environment variable should I use?

Use TYPESAFE_API_KEY in your local shell, server environment, or CI secret store. The variable name is intentionally provider-neutral so your application code can stay consistent across supported access paths.

How often should I rotate my key?

Follow your team's security policy and rotate immediately after suspected exposure or an access change. For production, use the overlapping replacement flow in Rotate keys without downtime.

Can I use more than one key?

Yes. Separate keys by environment or service when your TokenRa account supports it. This improves usage attribution and lets you revoke one workload without taking down every other workload.

Can I put the key in a browser app?

No. Browser code and public mobile bundles are inspectable by users. Put the Jev call behind your server or an authenticated edge function and let the client call your own protected endpoint.

Ready to make the first request?

Get a key, set the environment variable, and start with the verification command.

Open TokenRa