Skip to content

API overview

A read-write REST surface over chatbots, knowledge, conversations, leads, channels, team, workspace, webhooks and reseller — scoped keys, every plan.

Available on 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

What you can do

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

  1. 1
    Authentication — a workspace API key of the form blm_…, on either an Authorization: Bearer or an x-api-key header. → Authentication
  2. 2
    Scopes — every key carries a fixed subset of the scope registry; each endpoint names the scope it needs, and a missing scope is a 403 naming it. → Scopes
  3. 3
    Available 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
  4. 4
    One 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
  5. 5
    Cursor pagination on the big lists — limit up to 200, page until nextCursor is null; a few endpoints use skip/take offsets instead. → Pagination
  6. 6
    A 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

first-request.sh

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