Get categories, scores, and probabilities
through one API.
Send text, questions, and answer options.
Retrieve structured results for your application.
Checking availability…
Bring Jev AI
into your workflow.
Classify text, score inputs, and make yes/no decisions in your app or agent.
Create a key, then give your coding agent the setup prompt to connect Jev.
Connect your agent to Jev AI
Copy this setup prompt into the coding agent building your app or AI agent.
Add Jev to this app or AI agent using the UseJevAI API. Review the existing project and the guide at https://usejevai.com/jev-api, including its code examples, before making changes.
Configure USEJEVAI_BASE_URL and USEJEVAI_API_KEY on the server. Create a key at https://usejevai.com/settings/apikeys and send it as Authorization: Bearer <USEJEVAI_API_KEY>. Use https://usejevai.com as the base URL. Keep the key out of browser code, logs, Git, and chat, and show me where to set it locally and in deployment.
Use POST /api/v1/runs to submit text and questions, then GET /api/v1/runs/{id} to retrieve the result. Follow the guide for choice, score, and yes/no questions and the {code, message, data} response format. This is a queued API; the server selects Jev.
Start with funding: "prefer_trial". Use purchased tokens only when I select them. Give each new run a unique idempotencyKey; retry uncertain submissions with the same key and unchanged payload. Follow the guide for limits and error handling.
First check GET /api/jev/status for enabled API access and inference, then GET /api/v1/runs?limit=1 with my key to verify access without running inference. Once connected, ask before one small test using my balance, retrieve the result, and report whether it worked.Create once, then check the result
- Create a run with POST /api/v1/runs. The response includes its ID in data.
- Check the run’s status with the GET endpoint below, using the same Bearer key. Keep checking while queued or running.
GET /api/v1/runs/{id} - When the status is succeeded, read result. If it is unknown, wait for review; don’t submit another run.
Purchased tokens are used only when you select them.
idempotencyKey — Use a unique identifier for each new run. Reuse it with the unchanged payload only when retrying an uncertain submission.
| Limit | Trial tokens | Purchased tokens |
|---|---|---|
| Concurrent runs | 3 | 10 |
| Attempts per minute | 20 | 60 |
| Billable input tokens per run | 10,000 | 32,000 |
| Questions per run | 10 | 32 |
| Rows per batch | 20 | 100 |
Limits apply per account across Playground, Batch, and API. Each batch row counts as one run. Trial requests also share a site-wide budget. The daily budget resets at 00:00 UTC; the cumulative limit still applies.
Check the HTTP status and code/message before reading data. Keep your API key on your server. Don’t switch to purchased tokens unless the user selected them.
Describe the task
Provide the context as state. Give each question a stable identifier, a type, and instructions describing what it should judge.
Choose a response type
choice selects a category; score uses an ordered scale; noul represents a Yes / No probability.
Choose the token balance
Use the same API key for trial and purchased tokens. Set funding in each request to choose which balance to use.
Request fields
Send input, funding, and idempotencyKey. Input contains state and a questions array.
fundingPurchased tokens are used only when you select them.input.stateThe text or context needed to make the decision.input.questionsArray of questions with unique id, type, instructions, and options.typeOne of choice, score, or noul.instructionsA specific question, including your criteria for judging it.optionsArray of label/description objects for choice and score; empty array for noul.Integration questions
What should I do with the response?
Check the run status first. When it succeeds, read answers by question ID and inspect the selected category, score, or Yes / No probability. Use your own review rules for uncertain results.
Does creating a key enable API access?
No. You can manage keys in your account, but requests only run when API access is enabled. Check the API availability notice on this page.
How will usage be charged?
Playground, Batch, and API use the same account balances. Each successful run deducts input tokens from the balance you selected. A run never mixes trial and purchased tokens.
What about errors and retries?
Use a unique idempotencyKey for each new run. When retrying the same submission, keep its key and input unchanged. Fix any input, access, or limit errors first. If the run status is unknown, wait for review instead of submitting it again.
Test the categories and rules before integrating.
Open Playground