The call does not end in our system

The REST API: what you can do from outside

The public API authenticates with a key, and every key carries precise scopes — read-only, placing calls, writing flows, writing to the knowledge base — so a small integration does not get the run of the system. The key is shown once at creation and stored on our side only as a hash. Common operations: queue an outbound call, fetch a conversation with its transcript and summary, manage flows, and add knowledge-base entries. One important detail: an entry created through the API lands as a draft, and in-app human approval is still required before the agent can use it.

• API-key authentication with per-operation scopes
• Queue an outbound call in one request, optionally attached to a campaign
• Fetch conversations with transcript, summary, sentiment and outcome
• Manage flows and the knowledge base, including generating a flow from a script document
• Live OpenAPI reference covering every endpoint

Signed webhooks at the end of every call

Instead of polling us to ask whether a call finished, the system tells you: call queued, call completed, call failed, and a conversation finished on any of the voice channels. Every delivery is HMAC-signed over a timestamp and the body, so you can verify it genuinely came from us and was not replayed. The completion event is sent only once the summary and sentiment are ready, because a webhook that arrives empty is worth roughly nothing. A delivery log is kept per endpoint, and that is the first place to look when something did not arrive.

Write-back to Salesforce and HubSpot

When a call ends, a summarised activity is written into your CRM: a completed Task in Salesforce or a call engagement in HubSpot, linked to the right lead or contact, carrying the summary, sentiment and outcome. The activity can be assigned to an owner by email address, so the rep gets notified about a call that concerns them rather than finding it at the weekend. A CRM write failure never fails the call — it is recorded on the request so it can be fixed, rather than quietly leaving records missing.

An MCP server: build the agent from Claude or ChatGPT

A remote MCP server exposes a small set of business-meaningful operations — generate a flow from a script document, create an agent, update its models and flow, add a knowledge-base entry, place a test call and check the result. In practice a business owner can describe in plain language what they want the agent to do and watch it happen, without touching the interface and without writing code. Connecting is either a normal account sign-in or pasting an API key, and the key's scopes decide which operations are offered at all — a tool the key cannot use simply does not exist for it.

What the agent can reach mid-call

The difference between "let me check and get back to you" and a real answer is data access during the call. You can connect your systems as tools the agent calls mid-conversation, and you can also — with no development at all — upload a CSV or Excel file as a data table, which the agent filters and enumerates from inside the system, without the data leaving it. What an agent is allowed to call is governed at the department level and at the agent level, so an agent does not inherit every tool in the organisation just because it exists.

Security, permissions and the limits of these integrations

Every administrative action is written to the audit log, content access is role-based, and webhook secrets are stored encrypted and can be rotated. A key that starts dialling at an abnormal rate is suspended automatically and can be released from the interface — so a scripting mistake does not become a phone bill. And what should not be promised: these are API integrations, not a plugin installed inside your CRM and not two-way object sync; if your internal system exposes no interface at all, no integration can invent one. In that case, start with a data table and webhooks, and connect depth later.