---
title: "Voicetta API"
description: "Send voice calls, SMS and WhatsApp conversations from Voicetta into your dashboard, CRM, PMS, or reporting tool — automatically through webhooks or on demand through the REST API."
publishedAt: "2026-08-22"
modifiedAt: "2026-08-22"
category: "Integrations"
tags: "Voicetta, API, webhook, integration, SMS, WhatsApp, reporting, white label, communication"
navOrder: "59"
canonical: "https://voicetta.com/docs/conversation-data-api"
---

# Voicetta API

Every conversation your agents handle can flow into a system you already use — your dashboard, CRM, PMS, reporting tool, or workflow.

This page is the business view: what you can send, why teams use it, and what to ask your developer for. The technical reference lives in the [developer documentation](/developers/overview).

## Why it matters for your business

Voicetta shows you every conversation inside app.voicetta.com. That is the right place to review a Guest exchange, listen to a recording, or check a quality score. It is not always the right place for everything else.

Three situations where sending the data somewhere else changes what you can do:

- **Your team already lives in another tool.** If your front desk works in a PMS and your sales team works in a CRM, a Guest conversation is worth more attached to the record they already have open than in a second tab they have to remember to check.
- **You resell Voicetta under your own brand.** Agencies and software vendors run Voicetta behind their own product. Your clients log into your dashboard and see their Guest conversations there, with no Voicetta branding anywhere in the experience.
- **You report on more than conversations.** Quality scores next to revenue, response times next to staffing — the joins that matter usually happen in your warehouse or BI tool, not in ours.

In each case the value is the same: the conversation stops being something a person has to go and look up, and becomes something your existing systems already know about.

## What you can send

Three kinds of record, each available separately, so you send only what a given system needs.

| Record | What it contains | When it is ready |
|---|---|---|
| **A voice call** | Transcript, summary, what the Guest wanted, quality scores, a recording link | A few seconds after the call ends |
| **A text message** | The Guest's SMS or WhatsApp message and, when applicable, the reply your agent sent in the same turn | Within about 15–30 seconds |
| **A finished text conversation** | The whole exchange, summarised and graded, with quality scores | About 30 minutes after the last message |

Text messages and finished conversations are linked through the same conversation id. Most teams use both:

- **Messages** are the live feed — useful for a screen someone watches during the day.
- **Finished conversations** are the outcome — useful for reporting, because that is when the summary and quality scores exist.

The half-hour wait on finished text conversations is not a delay we could remove. A text conversation is not over when a message arrives; the Guest may reply in ten minutes. Grading waits for the conversation to actually finish, so the scores describe the whole exchange rather than a fragment of it.

## Two ways to receive it

**Webhooks — sent to you automatically.** You give us a web address and we deliver each record there as it happens. This is the normal choice: your data stays current with nothing to schedule.

**REST API — fetched when you ask.** Your developer requests records over the API — useful for loading history, for a nightly report, or for catching up if your system was offline.

Most integrations use both: webhooks to stay current, and the API to backfill everything from before the integration existed.

One API key can read voice calls, messages, and finished text conversations. Webhook events are configured separately, per endpoint.

## Choosing what leaves Voicetta

You control what each destination receives, block by block: Guest contact details, the transcript, the summary, quality scores, costs, and so on. Anything you do not tick is never sent.

This is worth a moment's thought rather than ticking everything. If a dashboard only ever shows a summary and an outcome, sending it full transcripts and phone numbers means Guest data sitting in a system that has no use for it — more to secure, and more to explain in your own privacy documentation. Send what the destination actually displays.

Cost figures are off by default, because they reveal what a conversation cost to run. Turn them on when the destination is yours, leave them off when a client logs into it.

**One note on text costs:** the cost shown on a message or a text conversation is an indicative rate, not a billed amount. Text messaging is not deducted from your wallet per message, so those figures are useful as an approximation and should not be used for invoicing. Your Voicetta invoice remains the source of truth — see [Billing, Wallet, and Pricing](/docs/billing-and-wallet).

## Setting it up

1. Open **Settings → Developers** in app.voicetta.com.
2. Add a webhook endpoint or API key — or both.
3. Choose which events and data blocks each destination should receive.
4. Press **Send test event** to confirm the receiving system answers correctly. You can do this as often as you like.
5. Watch the delivery log for the first day. It shows every attempt, the event type, and the response.

Keys and signing secrets are shown once, at creation — if one is lost, replace it rather than asking us to look it up, because we genuinely cannot.

**Turning an event on is not retroactive.** Enable text messages today and you receive messages from today onward; anything earlier is available through the API. Worth knowing before someone concludes the integration is broken.

## Do you need a developer?

For receiving records into a workflow tool — n8n, Make, or Zapier — no. Those tools have a webhook step that receives deliveries with no code involved, and there is a [page on exactly that](/developers/n8n) with the settings that decide whether it holds up in production.

For anything that writes into your own product or database, yes. Point them at the [developer documentation](/developers/overview); start with the [quickstart](/developers/quickstart) if they want a working handler in an afternoon.

## Related pages

- [Developer documentation](/developers/overview)
- [Quickstart](/developers/quickstart)
- [SMS Channel](/docs/sms-channel)
- [WhatsApp Channel](/docs/whatsapp-channel)
- [AI Evaluations](/docs/ai-evaluations)
- [History and Guest Timelines](/docs/history-and-timelines)
- [Integrations Overview](/docs/integrations-overview)
- [Billing, Wallet, and Pricing](/docs/billing-and-wallet)