The concept mapping
Our knowledge base is not vector search, and the difference will change how you build it.We crawl the site you point us at, transcribe each page you select, and generate a table of contents — one line per page, a title and a summary. That table of contents is what goes into the agent’s prompt; the page content does not. When the agent needs a page it calls
knowledge_fetch and gets that page back.So the model navigates rather than retrieves. It is good at “which page answers this” and it never returns a decontextualized paragraph from the middle of a document. It is worse at “find the one sentence mentioning this part number across nine hundred pages”, which is what an embedding index is for. It is also worth knowing that the only sources are websites and the PDFs linked from them — there is no file upload, and no Drive, Notion or Confluence connector.If your Vapi knowledge base is a pile of uploaded files, that content has to be reachable at a URL before it can come across.What is different, and worth knowing before you plan
Draft and published are real, and publishing pins tool versions. Every write lands on the draft; live traffic runs the last published version, which is an immutable snapshot. Publishing an agent pins each attached tool to the tool version that is live at that moment — so republishing a tool does not change any live behaviour until the agent is published again. That is a feature when you are editing a tool six agents share, and a surprise the first time you expect an edit to take effect. See versions. A write replaces the whole config.POST /v1/agents and PATCH /v1/agents/{agent_id} both take the complete config, not a patch. Anything you leave out reverts to its default — omitting tools detaches every tool, omitting handoffs deletes every destination. Read the current config, change it, send it back. Any migration script you write has to be built that way from the first line.
A phone number needs a published voice agent, and one specific thing must hold. The agent must be voice — a video agent cannot answer a number — and it must not declare a required variable with no default. An inbound call carries no request of ours to supply one, so assigning the number, publishing that config under a number already assigned, and rolling back to it are all refused. Anything an inbound agent needs must have a default.
Bring-your-own-key is strict, and the platform fee is our only charge. Model, speech and avatar spend goes to your own provider accounts on your own keys; we add a per-minute platform fee on voice and video, and no fee at all on text. There is no bundled model price and no resold minute anywhere in the product. See pricing and credits.
Regions are real and resources belong to one. An agent, a tool, a task, a call, a phone number and the credit balance belong to the base URL they were created against — https://api.in.talqing.com or https://api.us.talqing.com. Your token is not regional and reaches both. Migrating into the wrong region means recreating, not moving. See regions.
What we do not have
Read this list before you plan anything, because finding one of these out later is worse than reading it now. None of the following exists on Talqing today, in any form, under any name:- Answering-machine detection. A call that reaches voicemail is answered, billed and reported as completed. If your outbound campaign depends on machine detection, it will not behave the way it does today.
- DTMF. No sending or collecting keypad tones, so no IVR menus and no navigating someone else’s phone tree.
- SMS. No text messaging of any kind on a phone number. Outbound email exists; SMS does not.
- Live call monitoring or barge-in. You cannot listen to a call in progress or join one. You read a call after it ends.
- Staged environments. There is draft and there is published — no separate test and production projects, and no promote step between them.
- Automated agent testing. No test suites, no scripted callers, no scored runs. Testing is a real call or a real chat.
- An audit log. There is no record of who changed what and when.
- Configurable concurrency or spend caps. No account-level cap on concurrent calls, no budget ceiling, no per-call duration limit you set. A batch has
max_concurrency; nothing else does. - An embeddable chat widget. Web chat is an SDK integration you build. See website chat.
A migration checklist
1
Add your provider keys
On the BYOK page, add a key for every provider your model stack names — speech-to-text, LLM, text-to-speech, and any fallback. Each key is verified with the provider when it is saved, and an agent whose provider has no key will not publish. See provider keys.
2
Recreate the agent
Paste the prompt across, then pick models from
GET /v1/catalog, which is the only source of valid provider and model pairs and also states what each supports — channels, languages, speed range, default voice. Set language once on the agent; there is no language field on the individual models. See models.3
Rebuild each tool as an operation tree
Take each function one at a time and ask what still needs a server. A tool that fetched a record and let the model narrate it is an
http operation and nothing else. One that fetched, reshaped and branched is http → code → if, with no endpoint of yours in the middle. Keep the argument schema close to what you have — every property needs a description, because that is the only instruction the model gets about what to put there. Then validate and publish each tool: an unpublished tool cannot be attached. See tools.4
Attach knowledge
Point a knowledge base at your documentation site, choose the pages worth indexing at the review step, and build. Read
GET /v1/knowledge/{kb_id}/prompt afterwards — it returns the table of contents exactly as the agent receives it, and a vague entry is one the agent will never fetch. Attach ready ones through kb_ids. See building a knowledge base.5
Validate and publish
POST /v1/agents/{agent_id}/validate reports errors and warnings against the same rules publishing enforces. Fix the errors, read the warnings, then publish. Publishing is what pins your tool versions. See validation.6
Connect your carrier and import your number
Create a carrier account for Plivo, Twilio, Vobiz or Exotel, provision it, then import the numbers that account already owns. Numbers are bought in the carrier’s console, never here. Some carrier work happens in that console and no API can confirm it — an account’s
setup_steps names anything outstanding. See carrier accounts and phone numbers.7
Assign the agent and make one real call
Assign the published voice agent to the number and check
readiness reads live rather than needs_agent or needs_carrier_setup. Then call it. There is no dry-run mode and no sandbox: a test call is a real, billable call. Read the whole record afterwards — GET /v1/calls/{session_id} gives the transcript with every tool call and its output, plus a per-stage latency breakdown, which is where you find out why something was slow. See the call record.8
Move traffic
Point the number at the new agent when the transcripts read the way the old ones did. Keeping the old assistant running in parallel costs nothing here, since a number that is not pointed at an agent takes no calls.
Next
Core concepts
Agent, tool, task, conversation, call, session — the vocabulary, once.
The operation tree
The part of the model that is most unlike what you have today.
Inbound support line
The same pieces built end to end, from nothing to a number taking calls.