Setup
Authenticate and start using the generated OutEvalAI public API reference.
The OutEvalAI API lets an existing CRM, operations system, or internal application manage the same core records your team uses in the dashboard. Use it to provision agents, synchronize leads, configure calling use cases, run agent evaluations, and read test outcomes without duplicating manual work.
Open the generated API Reference to browse every supported endpoint, request and response schema, code example, and the interactive playground.
API prefixes
| Prefix | Purpose | Authentication |
|---|---|---|
/api/v1/public | Workspace, agents, use cases, leads, calls, and evaluation runs | Bearer API key |
API Key
Create and manage API keys from the workspace topbar or admin options.
- Click View API Key in the dashboard header
- Copy your workspace API key
Treat an API key like a password. Keep it in a server-side secret manager, send it only over HTTPS, and never place it in browser code, screenshots, support messages, source control, or a Postman shared initial value. Create separate keys for separate environments or integrations so each one can be revoked independently.
Headers
Authorization: Bearer <api-key>Base URL
Production:
https://outevalai.comExample:
curl https://outevalai.com/api/v1/public/workspace \
-H "Authorization: Bearer <api-key>"Errors and request IDs
Every public API response includes an X-Request-ID header. Send your own safe request ID when you
need to correlate a request across systems, or let OutEvalAI generate one. Include this value when
contacting support.
Errors use one stable envelope:
{
"error": {
"code": "validation_error",
"message": "Unprocessable Entity",
"request_id": "a72d84c2-7e36-4a3e-a9cc-e6adad589e17",
"retryable": false,
"details": []
}
}The HTTP status remains authoritative. The retryable field identifies transient failures that may
succeed when repeated without changing the request. For mutations, it is true only when the
request included an Idempotency-Key backed by persisted replay semantics. Clients must additionally
confirm that the operation supports idempotency before retrying. The details field is optional and
may contain structured validation context.
Pagination
Agent, usecase, lead, and call list endpoints support opt-in cursor pagination:
- send
limitfrom1to100; - read
X-Next-CursorandX-Has-Morefrom the response; - send the returned cursor unchanged as the next request's
cursor; - stop when
X-Has-Moreisfalse.
Existing integrations that omit both limit and cursor retain the original unpaginated v1
response. New integrations should always request bounded pages. A request containing cursor but
no limit uses a page size of 50.
Rate limits and retries
Rate-limited responses use status 429 and include Retry-After plus
X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers when available. Retry
429, transient 5xx, and network timeouts with bounded exponential backoff and jitter. Honor
Retry-After when present.
Do not automatically retry create, update, or delete requests after an ambiguous timeout unless the
operation documents Idempotency-Key support and the caller supplied a stable key. Agent creation
and lead creation currently support persisted replay semantics; other mutations do not.
API reference
Authenticated REST API
Workspace
Agents
Use Cases
Evaluation Personas
Evaluation Scenarios
Evaluation Runs
Integration pattern
For a reliable integration, store OutEvalAI IDs alongside your corresponding internal records.
- Create or select an agent, then store its
agent_idin your integration configuration. - Create personas and scenarios to evaluate your agent automatically.
- Start evaluation runs and inspect pass/fail results, transcripts, and AI suggestions.
- Make retries idempotent in your own worker: record successful IDs before retrying a batch.
- Treat
401as an invalid or revoked key,403as a workspace entitlement or policy restriction,404as an ID outside the authenticated workspace, and422as invalid request data.
The interactive playground sends requests through the OutEvalAI docs server so the key is never embedded in client-side source. The key remains in memory only while the playground is open and is cleared when it closes, navigates, or unloads. For production integrations, make requests from your own backend rather than from a public browser session.
How is this guide?
