Every conversation your agents handle can flow into a system you already use — your dashboard, CRM, PMS, reporting tool, or workflow. And your own system can start a call, rather than someone pressing a button in ours.
This page is the business view: what you can send, what you can start, why teams use it, and what to ask your developer for. The technical reference lives in the developer documentation.
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.
And one situation where the data flows the other way:
- The call should happen when something else happens. A Guest submits a form, a booking is confirmed, a lead has been quiet for three days. Someone noticing and pressing a button is the slow, forgettable part of that. Your system can start the call the moment the trigger fires, at two in the morning if that is when the trigger fires.
Starting a call from your own system
Your system tells Voicetta which agent to use and which number to ring, and the agent places the call. Everything else is the setup you already have: the same prompt, the same number, the same restrictions, and the finished call in History like any other.
The part worth understanding is that each call can carry its own details. Write {{placeholders}} into the agent's prompt — the property name, the Guest's name, their arrival date — and your system fills them in per call. That is what lets one agent handle every Guest rather than needing an agent per Guest, or per property.
You are calling on behalf of {{hotel_name}} to confirm a reservation.
{{participant_name}} arrives on {{check_in_date}}.Two practical notes:
- Permission is separate and off by default. An API key can read conversations without being able to place calls. Ticking Place outbound calls in Settings → Developers is a deliberate, separate step, including on keys that already exist — because reading a transcript and ringing a Guest are different decisions and one should not quietly grant the other.
- These are real, billed calls. There is no practice mode. Ask your developer to point the first one at their own phone.
Your developer will want the Outbound Calls API and Dynamic Variables pages, plus your agent's ID from the Agent page in app.voicetta.com.
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 |
There is also a lighter notification for a call your system started: that it has begun ringing. It carries who is being called and nothing else, because a transcript and a quality score do not exist until the call is over. Useful for showing "calling now" on a screen; the full record follows when the call ends.
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, and — if you tick the extra permission — start calls. 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.
Setting it up
- Open Settings → Developers in app.voicetta.com.
- Add a webhook endpoint or API key — or both.
- Choose which events and data blocks each destination should receive.
- Press Send test event to confirm the receiving system answers correctly. You can do this as often as you like.
- 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 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; start with the quickstart if they want a working handler in an afternoon.
For starting calls from your own system, yes — that one needs a developer. It is a few lines of code rather than a project, but it is code.