Professional services

Voka for teams that need more than the self-serve product

Most businesses set Voka up themselves in an afternoon and never touch an API. This page is for the ones who cannot: the platform embedding a voice assistant for its own customers, the practice whose booking system nobody else supports, the team that wants every finished call to land in something they already run.

There is a public REST API, signed webhooks on every call, official apps on n8n, Zapier and Make, and a way to let the assistant call your own tools mid-call. Where that still is not enough, Voka takes paid fixed-fee engagements to build the missing piece.

Free 14-day trial (100 minutes, whichever comes first), no credit card to start.

Your system decides. Voka makes the call.

POST/api/v1/outbound-calls

{
  "assistant_id": "9f3c…",
  "to": "+15555550123",
  "variables": {
    "client_name": "Dana",
    "case_ref": "PL-4417"
  },
  "metadata": { "crm_id": "8842" }
}

When the call ends, signed to your endpoint

call.completed

Your metadata comes back attached to it.

Voka AI is an AI voice receptionist that most businesses set up themselves, and it also exposes a public REST API under /api/v1 for teams that need to drive it from their own systems. That API reads calls, transcripts and assistants, places outbound calls on a trigger your own workflow decides, and sends signed webhooks when a call completes. Anything Voka does not integrate with can be reached through your own Model Context Protocol server, which the assistant calls live during the conversation. Where none of that is enough, Voka takes paid fixed-fee engagements on a case-by-case basis to build the connector itself.

What Voka exposes

Four surfaces, all shipped, all documented

Nothing below is a roadmap item. Each one also carries what it will not do, because the gap between what a platform sounds like it does and what it does is where an integration project goes wrong.

Events out

Every finished call can land in your system

  • POST /api/v1/webhook-subscriptions
  • call.completed
  • call.transcript.ready
  • call.insight.received

Subscribe an endpoint of yours to Voka call events and each one is delivered to you after the call, signed, so you can act on it in whatever you already run.

Three events, and they mean what they say
call.completed fires once a call has ended and its post-processing has finished. call.transcript.ready fires when the full transcript is available, which is shortly after. call.insight.received fires once the AI analysis of that call has been processed.
Signed, with a secret you are shown once
Each delivery is signed with HMAC-SHA256 over the timestamp and the raw body, using a per-subscription secret returned exactly once when you create the subscription. A timestamp header travels with the delivery so you can reject a replayed one.
Your own reference comes back with the call
Anything you attached as metadata when you started a call is opaque to Voka and is handed back on the completion event, so you can match a result to the record that caused it without keeping a lookup table.

Where it stops

These are deliveries, not a rules engine. Voka sends you the event; deciding what counts as important and what should happen next is your side of the line. There is no screen in the product where you describe a condition and have Voka act on it for you.

The API

A versioned REST API with keys you scope yourself

  • GET /api/v1/calls
  • GET /api/v1/calls/{id}
  • GET /api/v1/calls/{id}/transcript
  • GET /api/v1/assistants

Read calls, pull a transcript on demand, list and fetch assistants, and place a call. It is the same surface the automation platforms are built on, so anything they can do you can do directly.

Keys are scoped and revocable
You create keys in the portal against the scopes you actually need (read_calls, read_assistants, manage_webhooks, outbound_calls) and revoke them there too. The full key is shown once, at creation.
Versioned, so an upgrade is not a surprise
Everything sits under the /api/v1 prefix. Reference documentation, payload shapes and error codes live at docs.vokaai.com.

Where it stops

The API reads calls and assistants and places calls. It is not a management API for the whole product: creating a business, editing an assistant’s configuration or changing a plan is done in the dashboard, not over HTTP.

Outbound

Voka will place the call. Deciding to place it is your job

  • POST /api/v1/outbound-calls
  • assistant_id
  • to (E.164)
  • variables
  • metadata

This is the part people get wrong, so it is worth being blunt. Voka does not dial anyone on its own. There is no campaign screen, no schedule and nothing in the product that decides a call should go out tomorrow morning. Your workflow decides that, and then asks Voka to make the call.

What goes in the request
The assistant that should make the call, and the number to dial in E.164. Optionally a callback URL for status updates as the call progresses.
Dynamic variables are how the call knows anything
Pass a variables object and its values are interpolated into the assistant’s prompt for that one call. That is the mechanism by which an outbound call can refer to a specific person or a specific appointment rather than reading a generic script.
The trigger is whatever you already have
A row changing in your CRM, a booking landing in your own system, a form submission, a nightly job, or a Voka call.completed event feeding back round. Voka never sees the trigger; it only sees the request that results from it.

Where it stops

There is no scheduler, no retry policy and no contact list inside Voka. If a call needs to go out at a particular time, something on your side has to be awake at that time to ask for it. If it should be tried again after a no-answer, your workflow has to decide that and call the endpoint again. Setting that orchestration up is real work, and it is work you own.

Your own tools

Anything Voka does not integrate with, the assistant can still reach

  • Bring your own MCP server
  • Called live, mid-call
  • Included on every plan

Voka speaks the Model Context Protocol. Point an assistant at an MCP server you run, and it calls your tools during the conversation rather than after it. It can check an order, look up an account, open a ticket, or book against a system nobody else supports.

Real time, not a post-call export
The tool call happens while the caller is on the line, so its result can change what the assistant says next. That is the difference between an assistant that can answer a question about your system and one that files a note about it.
Any language, any stack
If you can expose it as an MCP server over HTTP, the assistant can use it. Add the server URL and its credentials to the assistant in the dashboard.
Not an upsell
Bringing your own MCP server is included on every Voka plan. The scheduling integrations are the paid add-ons, not this.

Where it stops

You run the server, and its reliability is yours. If your tool is slow, the caller hears the wait; if it is down, the assistant has to handle that gracefully rather than invent an answer. Voka will not build or host your MCP server for you unless that is the engagement you are asking for, which is the next section.

How it fits together

One outbound call, end to end

Three of these five steps are yours, and that is deliberate. The decisions worth auditing sit in your own workflow where you can read them, rather than behind a toggle in somebody else’s dashboard.

  1. 01You

    Something happens in your stack

    A booking is created, a record changes, a form is submitted, a scheduled job wakes up. This is the part Voka has no visibility into and no opinion about.

  2. 02You

    Your workflow decides a call should happen

    In n8n, Zapier, Make or your own code. Branching, filtering and timing all live here, where you can see them.

  3. 03Voka

    Voka places the call

    Your workflow posts to /api/v1/outbound-calls with the assistant, the number, the variables that make the call specific, and any metadata you want handed back later.

  4. 04Voka

    The call completes and Voka signs an event to you

    call.completed arrives at your endpoint with your metadata attached, and call.transcript.ready follows once the transcript is available.

  5. 05You

    You write the result back where it belongs

    The same workflow updates the record that started it. If the outcome warrants another call, it starts the loop again, because that decision is yours rather than Voka’s.

Where you build it

Three platforms, or none of them

The platform apps are conveniences over the same public API. Pick whichever your team already runs, or skip all three and call the endpoints yourself.

n8n

n8n

There is an official Voka community node, n8n-nodes-vokaai, installable from n8n’s community-nodes screen. It ships a trigger node that subscribes to the call events and verifies the signature for you, and an action node that lists calls, fetches one, pulls a transcript, lists assistants and places an outbound call. Self-hosted or cloud.

The n8n integration
Zapier

Zapier

An official Voka app, included on every voice plan, with call triggers carrying the full payload. Useful when the rest of the workflow already lives in the apps Zapier connects and nobody wants to run infrastructure for it.

The Zapier integration
Make

Make

An official Voka app, included on every voice plan. The same triggers, in a scenario builder that suits branching visually.

The Make integration

Your own code

None of the three is required. The API and the webhooks are the product surface; the platform apps are conveniences built on top of them.

All four ways in

Your own Model Context Protocol server is the fourth route in, and it is the only one that runs during the call rather than after it. How MCP works with Voka.

Before you build anything

A good deal of the depth is already in the box

Worth checking first. Several things teams set out to build turn out to be product behaviour they can switch on instead.

The assistant reads your live catalog on every call

Service names, prices, durations and staff are pulled from Square Appointments or Acuity Scheduling at call time, not copied into a prompt. Change a price this morning and it is quoted this afternoon.

What the assistant actually does

Square and Acuity are genuinely two-way, and not identical

Both book, reschedule, cancel and read real availability. Only Square does group and couples booking and deposits through a real invoice; only Acuity does intake forms, classes and packages.

The Square integration in detail

Acuity has depth Square does not, and the reverse

Intake forms that block a booking when a required field is missing, classes with capacity handling, packages redeemed at the point of booking, and a stricter identity check before a cancellation.

The Acuity integration in detail

The scheduling add-ons are cheap and the plans are month to month

Square Appointments and Acuity Scheduling are a $19.99/month add-on and Google Calendar is $9.99/month. Bringing your own MCP server costs nothing extra.

See pricing

Custom engagements

When the answer is not a setting, we will quote for building it

Some of what a business needs is not a setting. When the connector does not exist, when the assistant has to behave in a way the dashboard cannot express, or when Voka has to sit inside somebody else’s product, that is an engagement rather than a configuration.

  1. 01

    Tell us what the assistant has to reach

    A booking engine that is not on the list, an internal CRM, a ticketing system, a proprietary scheduler. If a phone call should touch it, it is in scope for the conversation. That conversation costs nothing.

  2. 02

    We scope it and quote a fixed fee

    Engagements are taken case by case and priced per project once the scope is clear, so the number is known before anything starts. There is no rate card, because there is no standard job.

  3. 03

    It runs on Voka infrastructure, with the same honesty bar

    The connector is monitored and handles its own failures. The rule that governs the Square and Acuity integrations governs a bespoke one too: the assistant says only what the system confirmed, and a caller never hears an invented confirmation or a raw error.

Where it stops

Voka is a two-person company, so this is not a services bench waiting for work and a scope that does not fit gets a straight no rather than a slow yes. Bring the timeline early, because it is usually the constraint that decides the answer. What is on offer is engineering: building and running an integration. There is no staffing, no managed-service tier and no retainer behind it.

Two that already run in production

A CRM platform, embedding Voka for its own customers

Voka runs as a dedicated voice assistant inside FuneralDecisions CRM, placing outbound calls on behalf of the funeral homes and preneed counselors that use it. One assistant, one CRM integration, the whole client base behind it.

The integration with our CRM was seamless, and the same assistant runs reliably across our entire client base.
Funeral Decisions

A software vendor, using Voka as its first-line support

Inbound support calls are answered, the issue is captured, and a structured ticket is opened in the vendor’s own ticketing system and routed onward. The assistant reaches an external system during the call instead of filing a note about it afterwards.

The assistant handles inbound support calls, captures the issue, automatically creates a structured ticket in Intercom, and routes it to an available specialist.
Kevin J., OmniPACS Health Technologies

What teams ask before they build against it

Does Voka AI have a public API?
Yes. Voka AI exposes a versioned REST API under the /api/v1 prefix. It lists and fetches calls, pulls a call transcript on demand, lists and fetches voice assistants, places outbound calls, and manages webhook subscriptions. Access is by API key, and keys are created and revoked in the Voka portal against the scopes you choose: read_calls, read_assistants, manage_webhooks and outbound_calls. The full key is displayed once, at creation. Reference documentation is at docs.vokaai.com.
Can Voka AI make outbound calls?
Yes, but it does not decide to. Voka AI exposes POST /api/v1/outbound-calls, and something on your side has to call it: an n8n, Zapier or Make workflow, or your own code. The request names the assistant to use and the number to dial in E.164, and can carry a variables object whose values are interpolated into that call’s prompt, plus opaque metadata that is handed back to you on the completion webhook. There is no dialer, no campaign screen, no contact list and no scheduler inside Voka, so if a call should go out at a particular time, your system is what has to be awake to ask for it.
What webhook events does Voka AI send?
Three. call.completed fires after a call has ended and its post-processing has finished, call.transcript.ready fires once the full transcript is available, and call.insight.received fires once the AI analysis of that call has been processed. You subscribe an endpoint through POST /api/v1/webhook-subscriptions. Every delivery is signed with HMAC-SHA256 over the timestamp and the raw request body, using a secret that is returned exactly once when the subscription is created, and each delivery carries a timestamp header so a replayed request can be rejected.
Does Voka AI work with n8n, Zapier and Make?
Yes, and on all three the app is included with a voice plan rather than sold as an add-on. n8n has an official Voka community node, n8n-nodes-vokaai, installable from the community-nodes screen: a trigger node that subscribes to the call events and verifies the HMAC signature for you, and an action node that lists calls, fetches a call, pulls a transcript, lists assistants and places an outbound call. Zapier and Make have official Voka apps with call triggers that carry the full payload. All three sit on the same public API, so none of them is required.
Can Voka AI connect to a system it does not already integrate with?
Yes, in two ways. If you can expose the system as a Model Context Protocol server over HTTP, you add its URL and credentials to your assistant and the assistant calls your tools live during the conversation, so the result can change what it says next. Bringing your own MCP server is included on every Voka plan. If you would rather not build and run that yourself, Voka builds bespoke connectors as a paid engagement, scoped and priced per project.
Does Voka AI do custom implementation work?
Yes. Voka’s Forward Deploy Engineering Services team takes paid fixed-fee engagements on a case-by-case basis. That covers custom connectors for platforms that are not supported out of the box, bespoke assistant behaviour, and embedding Voka inside another product. Work is scoped and priced per project before it starts, and the scoping conversation is free. Voka is a small team, so engagements are accepted selectively. Enquiries go to support@vokaai.com.
What does a custom Voka AI engagement cost?
There is no rate card, because there is no standard job. Engagements are scoped and quoted as a fixed fee once the requirement is clear, and the scoping conversation costs nothing. For comparison, the self-serve product is month to month with no contract: plans run from $19 to $229 a month, the Square Appointments and Acuity Scheduling add-on is $19.99 a month, Google Calendar is $9.99 a month, and connecting your own MCP server is included on every plan.
Is there a Voka AI page for law firms, accountants or financial planners?
Yes. Voka AI publishes a dedicated page for each: /law-firm-ai-receptionist covers intake calls and consultation booking for law firms, /accounting-ai-receptionist covers accounting and CPA practices, and /financial-planning-ai-receptionist covers financial planning firms. Those pages describe the standard self-serve product for those verticals. This page covers the API, the automation platforms and custom engineering work.

Start with the product. Call us when it runs out

The API, the signed webhooks and your own MCP server are there from the first day, on every plan. An engagement is for the part that is genuinely yours alone.