The Callario API

The Callario API is a REST API over the same data model the product uses — the conversations, tickets, and contacts you see in the app are the resources you read and write programmatically.

It's designed for the integration work mid-market support teams actually do: syncing customer context in, pushing support events out, and wiring Callario into the rest of your stack. This page is a conceptual orientation, not an endpoint-by-endpoint reference.

The API lives under a versioned path so changes are additive and predictable. Build against the version you onboard on and migrate on your own schedule.

Authenticate with API keys rather than user credentials. Keys are scoped: each one carries only the permissions you grant it, so an integration that reads contacts doesn't also gain the ability to delete tickets.

Treat keys as secrets — store them server-side, never ship them in client code or a browser bundle, and issue a separate key per integration so you can rotate or revoke one without breaking the others.

Scoping is the principle throughout: grant least privilege, rotate on a schedule, and revoke immediately if a key is exposed.

Conversations represent threads across channels — web chat, email, and the rest — including the messages, the AI agent's turns, and the resolution outcome.

Tickets are the unit of support work: status, assignment, SLA state, and history. They link to the contact they belong to and the conversation they came from.

Contacts are the CRM record — identities, organizations, custom fields, consent, and notes — and they're the same governed profiles the AI agent draws on for context. Because every resource shares one data model, a contact you create over the API is immediately visible to the inbox, routing, and the agent.

Subscribe to events — new conversations, ticket changes, resolution outcomes — and Callario will POST them to your endpoint as they happen, so you don't poll.

Every webhook is signed with a shared secret and a timestamp. Verify the signature on every request before you act on the payload, and reject requests whose timestamp is stale to defend against replay. Treat an unsigned or unverifiable request as hostile.

Delivery is durable: failed deliveries are retried, and you can replay events, so a brief outage on your side doesn't lose data. Make your handler idempotent — design for the same event arriving more than once.

The API is rate limited per key to keep the platform stable for everyone. Expect limits, handle them gracefully, and back off when you're throttled rather than hammering through.

Use webhooks instead of tight polling loops, batch where you can, and spread bulk work over time. Well-behaved integrations rarely meet the ceiling.

Build retries with exponential backoff and respect the signals the API gives you. The limits exist to protect your integration as much as ours.