Skip to content
Apolaris AI Docs

Integrations & webhooks

developer

Machine integrations and where to explore the API live.

Apolaris AI ships a live, self-describing API surface and a separate authentication path for machine-to-machine bridges. Instead of guessing at endpoints or wiring up brittle screen-scraping, you get an interactive reference that always matches the running build, plus a dedicated token model for unattended workers.

Explore the API live

Two endpoints let you discover and exercise the API without leaving the browser:

  1. Open /api/docs/ — the interactive Swagger UI. Every resource, parameter, request body, and response shape is listed, grouped by tag, and you can fire authenticated requests directly from the page.
  2. Hit /api/schema/ — the raw OpenAPI 3.0 JSON spec. Point your code generator, Postman, or test tooling at it to scaffold a typed client.
# Download the machine-readable spec
curl https://your-domain.example.com/api/schema/ -o apolaris-openapi.json

Because the spec is generated from the live code, your generated clients and the server never drift apart — there is no hand-maintained doc to fall out of date.

The same Swagger reference is linked from the control panel under API Docs and from your profile's API tokens screen.

Two kinds of credential

Pick the credential that matches who is calling.

  • Per-user API tokens authenticate a person's automation against /api/v1/. Every request scopes to that user's domain and visible sites and is gated by the same can_* privileges as the UI. See the REST API overview and API examples.
  • Shared bridge token authenticates trusted infrastructure — not a user. It is sent in the X-Bridge-Token header and is provisioned by Apolaris when your bridge integration is set up.

The bridge token is a shared secret with no per-user privilege scoping. Treat it like a server credential: keep it out of client-side code and rotate it if exposed.

Machine & bridge integrations

The X-Bridge-Token header is used by backend components that run unattended:

  1. The WhatsApp bridge for the Contact Center (CCaaS) — it reads queued outbound messages and posts inbound ones over the CCaaS bridge endpoints.
  2. Camera / edge workers for Cameras & AI Vision — they fetch their worker configuration and submit detected events.
# A camera worker fetching its config with the shared bridge token
curl https://your-domain.example.com/cameras/api/worker-config/ \
  -H "X-Bridge-Token: $BRIDGE_TOKEN"

These bridge endpoints are documented in Swagger under the CCaaS and Cameras tags, where the X-Bridge-Token parameter is marked required.

Connect the Contact Center to a third-party system

There are two integration shapes, and which you pick depends on what you're connecting.

1. React to conversations and bookings (most common). Your external system — a CRM, a marketing platform, a data warehouse — consumes Contact Center activity through the per-user REST API. Poll /api/v1/bookings/ and /api/v1/customers/ to mirror appointments the AI agent booked, or push leads the other way by creating customers and bookings. This needs only a per-user token scoped by the matching can_* privileges, and it's the right path for business logic. See API examples for ready-to-run sync and "book from your own site" recipes.

2. Bridge an alternative message transport. If you run your own messaging gateway (or a provider other than the built-in one), it authenticates as infrastructure with the X-Bridge-Token header and exchanges messages over the CCaaS bridge endpoints: it pulls the outbound messages the agent queued, delivers them through your transport, and posts inbound customer replies back so they land in the unified inbox.

# 1) Pull outbound messages the AI/agent queued.
#    (See Swagger → CCaaS tag for the exact path and request/response schema.)
curl https://your-domain.example.com/<ccaas-outbound-endpoint> \
  -H "X-Bridge-Token: $BRIDGE_TOKEN"

# 2) Deliver each message through your own provider, then
# 3) POST the customer's inbound replies back into the inbox.
curl -X POST https://your-domain.example.com/<ccaas-inbound-endpoint> \
  -H "X-Bridge-Token: $BRIDGE_TOKEN" -H "Content-Type: application/json" \
  -d '{ /* message fields per the CCaaS schema in Swagger */ }'

Use the per-user REST API for anything involving business data (bookings, customers, sales) and the bridge token only for transport-level infrastructure you fully control. The bridge token has no per-user scoping, so never hand it to a third party you don't trust — give them a privilege-scoped per-user token instead.

Tips

  • Browse /api/docs/ first; the tag groups map cleanly to product modules.
  • Use /api/schema/ to generate clients rather than hand-writing request code.
  • Never reuse a per-user token where a bridge token belongs, or vice versa — the scoping and lifecycle are different.
  • For broader context, start with the REST API overview and the Integrations & webhooks page you are reading.
API examples Roles at a glance