POST /v1/agents/{agent_id}/validate runs every check publishing runs, and publishes nothing. It returns two lists:
An error blocks a publish. A warning does not. Publishing calls the same validator, so anything in errors here is exactly what a publish would refuse, and POST /v1/agents/{agent_id}/publish returns the same warnings on success. Validation runs server-side against state a draft cannot be checked against by eye — the provider catalog, which tools are published, whether a knowledge base finished building, which provider keys the workspace holds, which phone numbers point at this agent. Call it before every publish rather than reasoning about the config. The TypeScript and Python samples below assume a configured client — see SDKs.
validate needs the editor role, like publish.

When each check runs

Not every check waits for publish. Creating or updating an agent already runs most of them and rejects the write, so a stored draft is never arbitrarily broken. A draft may reference a provider you have not brought a key for yet; a published agent may not, because it would fail on its first turn.

The error envelope

A failed publish is a 400 in the one error shape every Talqing endpoint uses:
message changes with what you were doing; errors is the same list validate would have returned. Both SDKs surface it the same way: error.errors on TalqingApiError (TypeScript) and error.errors on TalqingAPIError (Python). See errors.

Models and the pipeline

Voice, delivery and avatars

Language

A model that publishes no language list is left alone — the setting genuinely does not apply to it.

Prompt, greeting and handoff prose

The prompt, the greeting, and each handoff destination’s description, summary_prompt and message are substituted before the model or the caller sees them, so a token that resolves to nothing would reach them as literal braces.

Variables

The same rule is enforced from all three directions — assigning the number, publishing under one already assigned, and rolling back — so the state is not reachable by any route. See variables.

Tools, hooks and MCP servers

At publish, the operation trees of every attached and hook tool are validated too, so a tool whose tree breaks against this agent’s variables fails the agent’s publish. Those messages are documented under templating and data.

Knowledge bases

Handoffs

See handoffs for how to write the description the model routes on.

Recording, analysis and conversation memory

Vision

Screen share on a realtime agent is refused earlier, when the config is parsed — see Refusals that arrive as a 422.

Provider keys

Talqing is strictly bring-your-own-key: agents run on your provider accounts and we have none of our own to fall back on. At publish, every provider the config names must have a key. Turning call analysis on never demands a key the agent did not already need — left unset, analysis runs on the agent’s own language model. Provider keys are regional, like everything else a workspace owns. An agent that publishes in one region can fail to publish in another for this reason alone.

Warnings

Warnings are things worth knowing that do not stop a publish.

Refusals that arrive as a 422

A few states are refused when the config is parsed, before validation runs at all. They come back as 422 with the field named, not as a 400 with an errors list — and because such a config can never be stored, validate never reports them. Switching channel normalizes rather than refuses: a text agent drops stt, tts, realtime, greeting, language, turn handling, background audio, noise cancellation, vision input, recording, analysis and the avatar. See channels.

The same validator guards a call

There is one agent validator, and per-call configuration runs it too. An inline agent, an agent_override merged onto a published version, and every member of an agent_team are all checked by validate_agent_draft at publish strictness before the call starts — so a bad override is a 400 at create, naming the problem, rather than a call that connects and then fails. See per-call configuration.

Versions

Draft, publish, rollback, and how tool versions get pinned.

Provider keys

Which providers need a key, and what fails without one.

Errors

The error envelope, status codes and what to retry.