Connection Types

Testzilla can reach your agent through several connection types. Each targets a different execution path, so you can verify exactly the surface your users interact with.

Quick comparison

Connection type	What it tests	Availability	Browser required	How it’s billed
Phone — Inbound	Your agent receives a call: Testzilla dials in to your agent’s number and runs the tester on the call	Available	No	Per minute of call time (1-minute minimum)
Phone — Outbound	Your agent places a call: Testzilla provisions a dedicated number per test, your agent calls it, a predeployed agent answers, and the transcript is scored via post-call webhook	Available	No	Per minute of call time (1-minute minimum), plus a monthly per-number line charge
LLM Chat	Agent’s text LLM directly via the provider’s chat API	Available	No	Per round-trip
Web Chat	Real chat widget on a live website, driven by a headless browser	Available	Yes	Per round-trip
Web Voice	Browser WebRTC voice session via the provider’s web-call SDK	Available	Yes	Per run
Website	An ordinary (non voice/chat) website, driven step-by-step in a real browser by Testzilla’s own runner	Available	Yes	Per run (less for a deterministic replay)
REST / Webhook	Your agent behind a generic HTTP endpoint: Testzilla sends each tester message to your URL and reads the reply from the JSON response	Available	No	Per round-trip

For current credit rates on every connection type, see the Pricing page.

Phone direction is described from your agent’s (the agent under test) perspective: Inbound means your agent answers a call Testzilla places to it; Outbound means your agent dials a number Testzilla provides. Both directions are available today.

Credits are deducted per completed test. If a test cannot start (widget not detected, agent unreachable), no credits are charged.

---

Phone

Phone tests run a real phone call through your configured telephony integration (Retell or VAPI). This is the highest-fidelity path for agents deployed on a phone number: the full voice pipeline — telephony, ASR, LLM, TTS — is exercised exactly as a real caller would experience it.

Call direction is named from your agent’s (the agent under test) point of view.

Inbound — your agent receives the call (available today). Testzilla dials in to your agent’s phone number and runs the AI tester on the call. Use this when your agent is deployed on a number that real callers ring, and you want end-to-end telephony coverage: call routing, IVR behaviour, hold music, transfer flows, or anything that depends on the actual phone stack.

Outbound — your agent places the call (available today). Outbound works differently from inbound, not just in dial direction. Each outbound test gets its own dedicated phone number (provisioned on test creation, released on archive/delete). Your agent dials that number; the test’s predeployed Testzilla agent answers and runs the call autonomously (Testzilla does not drive it live); then a post-call webhook sends the transcript to Testzilla for evaluation and scoring. For the full inbound-vs-outbound breakdown, see Phone Testing: Inbound vs Outbound.

What you configure on the channel:

• Provider (Retell or VAPI)
• The agent’s inbound phone number (the number Testzilla dials)
• Provider credentials (API key, agent ID)

Billing: charged per minute of call time, rounded up to whole minutes (1-minute minimum). Outbound tests additionally carry a monthly subscription line item per provisioned outbound number, because each outbound test holds its own dedicated phone line for as long as the test exists. Outbound testing is part of paid memberships: an active paid plan is required to run outbound tests. For current rates, see the Pricing page.

---

LLM Chat

LLM Chat (llmChat) tests your agent’s text LLM directly via the provider’s native chat API — for Retell this is POST /create-chat + POST /create-chat-completion. No browser, no phone, no audio. The AI tester sends messages as text and receives replies as text, turn by turn, up to a configurable maximum.

This is the fastest and cheapest connection type. Use it as a high-frequency sanity check: run LLM Chat tests on every deploy to catch regressions in prompt logic, tool calls, and response content before spending credits on phone or browser tests.

When to use it: You want to verify the agent’s conversational logic, prompt instructions, dynamic variables, or tool responses quickly and cheaply. The agent does not need a phone number. Audio quality, TTS voice, and widget UI are out of scope.

What you configure on the channel:

• Provider (Retell or Vapi; ElevenLabs has no text-chat API)
• Agent ID (the agent must have chat enabled in the provider’s dashboard; voice-only agents will be rejected)

Billing: charged per round-trip (one tester message + one agent reply), so a 10-turn conversation is billed as 10 round-trips. LLM Chat is the lowest per-round-trip rate of any connection type; see the Pricing page for current rates.

Note

If you see “Cannot start a chat session with selected agent”, the agent’s chat mode is not enabled. Enable it in the provider’s dashboard for each agent you want to test via LLM Chat.

---

Web Chat

Web Chat (webChat) drives a real chat widget on a live website using a headless browser (Playwright). Testzilla navigates to the URL you specify, detects which chat widget vendor is present, opens the widget, and conducts the conversation by interacting with the actual DOM — the same way a real visitor would.

Widget vendor detection is automatic. Testzilla scores each known vendor against window globals and DOM signatures, then selects the highest-confidence match. Supported vendors with full implementations: Retell, Intercom, Drift, Crisp. Partially scaffolded: Zendesk, Tidio, LiveChat. For any other widget, a heuristic GenericConnector inspects the DOM to locate the input field and message container.

When to use it: Your agent is embedded as a chat widget on your website and you want to test the real end-user experience — widget open/close behaviour, iframe rendering, message display, and the widget’s own UI logic — not just the LLM underneath.

What you configure on the channel:

• The URL of the page hosting the chat widget
• Optionally: a vendor hint (e.g. retell, intercom) to skip auto-detection
• Optionally: a reply timeout (default 30 seconds; widget agents can be slower than direct API calls)

Billing: charged per round-trip, so a 10-turn conversation is billed as 10 round-trips. See the Pricing page for current rates.

Note

If auto-detection cannot confidently identify the widget (confidence below threshold), the test is marked failed and no credits are charged. A low_confidence_widget quality flag is set when detection succeeds but with reduced confidence.

---

Web Voice

Web Voice (webVoice) tests a browser-based voice agent through a real WebRTC session — the same path a visitor would use if they clicked a voice button on your website. Testzilla launches a headless Chromium instance, loads the provider’s web-call SDK, establishes a WebRTC call using a just-in-time access token, and conducts the conversation using synthesized tester audio.

The full voice pipeline is exercised: WebRTC media negotiation, the agent’s ASR, LLM, and TTS — in a browser context. This is distinct from a phone call: it validates the web embed rather than telephony.

When to use it: Your agent is deployed as a browser voice widget (e.g. via the Retell web widget) and you want end-to-end coverage of the WebRTC path, including browser media handling, SDK behaviour, and voice quality — not just the LLM.

What you configure on the channel:

• Voice provider — Retell, Vapi, or ElevenLabs. Retell mints the web-call token server-side using POST /v2/create-web-call; Vapi and ElevenLabs connect the browser SDK directly using the keys you supply.
• Voice test mode — SDK (instantiate the provider SDK directly) or Widget (drive the embedded voice widget on the target page)
• Agent ID (used to create the web call session)
• Optionally: sample rate (default 24000 Hz) and TTS voice settings for the tester

Billing: charged per run, regardless of call duration. See the Pricing page for current rates.

Preview

Web Voice is in preview. The tester’s text-to-speech voice (used to speak tester messages into the WebRTC session) is being finalized. Test results include a full transcript reconciled from the provider’s post-call transcript API. On channels whose integration supports call introspection, results also carry a full reconciled transcript with a tool-call timeline; the Use transcript reconciliation channel setting is on by default.

---

Website

Website (website) tests an ordinary website — one that is not a voice or chat agent. Testzilla drives a real browser through its own Cloud Run harness, follows your test’s natural-language task step by step, captures a screenshot per step, then scores pass/fail against the test’s criteria.

Unlike the other connection types, Website needs no provider integration — the runner is Testzilla-owned, so there is no Retell/Vapi/ElevenLabs account to connect (the integration picker is hidden for this type).

When to use it: You want to verify a normal web flow — a signup, a checkout, a form, a content page — end-to-end in a real browser, described in plain language rather than scripted selectors.

What you configure on the channel:

• website_url (required) — the page to start on
• Optionally a viewport (e.g. 1280x800, the default)
• Optionally a per-run step budget

The task, pass/fail, and BLOCKER criteria are the test’s normal prompt and criteria fields, exactly like the other connection types.

Billing: charged per run that records or self-heals the script; a deterministic replay of an existing recording is charged at a lower rate. See the Pricing page for current rates.

---

REST / Webhook

REST / Webhook (rest) tests any agent that is reachable over a plain HTTP endpoint, without a Retell/Vapi/ElevenLabs integration. It is an outbound request/response connection: for each turn, Testzilla sends the tester’s message to your endpoint and reads the agent’s reply out of the JSON response. Despite the name, Testzilla calls you — you do not point a webhook at Testzilla.

Because it exchanges text turn by turn, it behaves like LLM Chat for any custom or self-hosted agent: no browser, no phone, no provider account.

When to use it: Your agent is a custom API, an internal service, or a platform Testzilla does not integrate with directly, and you can expose an HTTP endpoint that accepts a message and returns a reply.

What you configure on the channel:

• rest_endpoint_url (required) — the absolute http(s) endpoint Testzilla calls each turn.
• rest_method — HTTP method (defaults to POST).
• rest_headers_json — a JSON object of request headers. Put authentication here, e.g. {"Authorization": "Bearer ..."}.
• rest_request_template — the JSON body template; {{input}} is substituted with the tester’s message (defaults to {"message": <input>}).
• rest_response_path — a dot-path into the JSON response that locates the agent’s reply text.
• rest_expect_status — the HTTP status treated as success (defaults to 200).

Billing: charged per round-trip (one tester message plus one agent reply), the same model as the other text connection types. See the Pricing page for current rates.

---

Choosing a connection type

I want to…	Use
Check agent logic on every deploy	LLM Chat
Test the exact phone experience end-to-end (agent receives the call)	Phone (Inbound)
Verify the chat widget on my website works	Web Chat
Verify the voice widget on my website works	Web Voice
Test an ordinary web flow (signup, checkout, form)	Website
Catch prompt regressions cheaply	LLM Chat
Test IVR routing or call transfer	Phone (Inbound)
Test a widget from an unknown vendor	Web Chat (GenericConnector)