What Voicebot is

Voicebot runs automated voice conversations: it dials out, answers inbound calls, speaks, recognises what the caller said, decides what to do next, and records the outcome.

Voicebot does not stand alone. It sits between your telephony and your information system, and nearly everything it does depends on data arriving from your side and results going back to it.

What you connect

A tenant is what the rest hangs on. We issue it, its administrator and the first API key in phase 1. Three things connect to it:

• Voice. A SIP trunk between Voicebot and your telephony. Without it nothing dials. See phase 1, step 2.
• Structure. Your organisational units mirrored into Voicebot as accounts, users, numbers and pools. This is the part you automate, starting at POST/v1/internal/account. See phase 2.
• Data. Call outcomes, history and recordings pulled back out into your own records. See consumption.

Scenarios, agents and schedules decide what the calls actually do. That work is phase 3.

A number is not a trunk

Creating a number through POST/v1/number registers a logical resource. It does not create a voice path. See why a trunk is not a number.

Deployment models

Voicebot comes in two shapes. The API surface and the object model are identical in both. What differs is who operates the installation and how many tenants live on it.

	Cloud	On-premise
Who runs it	we do	you do, inside your perimeter
Tenants per installation	many, isolated	normally one
Provisioning	we issue your tenant	we issue your tenant after installation

Note

Our team agrees deployment specifics with you separately, and this documentation does not cover them. Integration is the same work in both shapes, so none of the pages below branch on the deployment model.

Next

• Your first automated call — the shortest end-to-end path
• Object model — what a tenant, account and user actually are
• Integration guide — the full route