API overview
A read-write REST surface over chatbots, knowledge, conversations, leads, channels, team, workspace, webhooks and reseller — scoped keys, every plan.
The Evoriqa public API lets you drive your workspace from your own systems — read and write. What started as three read-only endpoints is now the complete v1 surface: ten endpoint families covering everything the dashboard does that makes sense over a key.
Base URL
https://app.evoriqa.com/api/v1What you can do
| Family | Surface | Scopes |
|---|---|---|
| Chatbots | Create, configure, and delete chatbots; widget settings, hours, actions, action runs | chatbots:* |
| Knowledge | Add URL/FAQ/manual/file sources, crawl sites, recrawl, reindex | knowledge:* |
| Conversations | Read threads, reply as an agent, resolve, assign, notes, bulk status, CSV | conversations:* |
| Leads | Read, update, delete, export leads | leads:* |
| Channels | Connect the seven omnichannel types, set reply mode (AI replies / Draft for review / Off), toggle, disconnect | channels:* |
| Analytics | The dashboard summary bundle and topic clustering | analytics:read |
| Team | Members, roles, invites | team:* |
| Workspace | Settings snapshot plus every individual setting | workspace:* |
| Webhooks | Configure endpoints per feature group, read the delivery log, inspect one delivery in full, and resend deliveries | workspace:* |
| Reseller | Client provisioning + handover invite, pooled-credit allocate and reclaim, limit overrides, white-label. Dashboard-only: client deletion, invite resend, BYO Stripe connect/plans/checkout links, pool top-up checkout, logo upload, single webhook-receipt detail | reseller:* |
Each endpoint's page in the sidebar documents its parameters, request body, and scope. A few dashboard flows are deliberately not in v1 — anything tied to a human session (workspace create/delete/switch, invite acceptance, Stripe checkout, step-up-protected deletion) and browser-side features like the PDF export.
The six things to know
- 1Authentication — a workspace API key of the form
blm_…, on either anAuthorization: Beareror anx-api-keyheader. → Authentication - 2Scopes — every key carries a fixed subset of the scope registry; each endpoint names the scope it needs, and a missing scope is a
403naming it. → Scopes - 3Available on every plan — the API is self-serve on Free, Starter, Pro, and Business (the plans differ only in their rate limit): create a key and call it. If you're a client of an agency or reseller, your provider turns the API on for your workspace first. → Authentication
- 4One envelope — every response is
{ "success": …, "data" | "error" }; the CSV exports are the only exception. Read only documented fields — unlisted ones aren't part of the contract. → Response envelope - 5Cursor pagination on the big lists —
limitup to 200, page untilnextCursorisnull; a few endpoints useskip/takeoffsets instead. → Pagination - 6A per-plan rate limit — a per-workspace budget that follows your plan (Free 10 · Starter 30 · Pro 60 · Business 300 req/min), a per-IP flood guard,
X-RateLimit-*headers on every response, plus stricter per-endpoint limits on exports, crawls, and topic clustering. → Rate limits
The full code-to-status table is on Errors.
A first request
curl https://app.evoriqa.com/api/v1/chatbots \
-H "Authorization: Bearer $EVORIQA_API_KEY"{
"success": true,
"data": {
"data": [{ "id": "…", "name": "Support bot", "publicId": "cb_…" }],
"nextCursor": null
}
}Writes are attributed to the owner
A key is not a member identity. Key-driven writes — agent replies, notes, assignments, source creation, settings changes — are recorded as the workspace owner in audit trails and attribution, and owner-protecting guards apply (for example, the owner's member row cannot be changed over the API).
What to use alongside the API
- Reacting to something happening — use webhooks, not polling. Nine events across four feature groups, configurable over the API itself.
- Building your own chat frontend — use the widget's public endpoints, which need no API key.
Where to go next
Last updated