Test mode

Test keys are a security property, not a flag: under a vcp_test_ key, all telephony routes to a mock provider. No PSTN dial ever originates from a test key, in either telephony mode, and a test-mode call never touches your Twilio subaccount. Dial outcomes (ringing, answering-machine detection, answer) are simulated deterministically and produce no billable usage.

Deterministic outcomes

Outcomes derive from the destination number, never from randomness, so the same number always behaves the same way and you can pick the behavior you want to exercise. The last digit selects the outcome:

Last digit	Outcome
0–5	A human answers
6–7	An answering machine, so AMD reports machine_start
8	Nobody answers
9	The carrier rejects the call

Want to test your retry policy? Dial a number ending in 8. Want to see how AMD-detected machines land as attempts? End in 6. What the dialer does with a machine_start verdict today is hang the call up and record a contact attempt in the machine state - a machine is never a conversation - and your fixtures can rely on that in both key modes.

Voicemail drop: policy changed, mechanism in flight

Leaving an artificial-voice voicemail is permitted under the executed Cold Outreach & Data Provenance Waiver - one of the programs that document covers, on the same terms as the rest: your list, your carrier, your duty. The policy gate that used to refuse it is gone. An artificial-voice voicemail is itself a regulated call, so it carries the AI-disclosure opener and every other floor control when it runs.

TODO (voice runtime / campaign engine): the mechanism is being built and is not described here, because nothing in /v1 drops a message yet. No request field turns it on, machine_start still ends in a hangup, and the deterministic 6–7 fixtures above are unaffected. When the drop ships, its request surface, its outcome state, and its metering land in the API reference first - that document is generated from the server, so it is the one that cannot describe a mechanism that does not run.

Test calls run in-request

POST /v1/agents/{id}/test-call behaves differently and honestly on the two key types:

• vcp_test_ key ("telephony": "mock"): the dial runs synchronously, in-request, running the full dial pipeline (dialability gate, materialization, seize, originate, AMD/status outcome), free, no PSTN. The 202 response’s state already carries the deterministic outcome. It exercises the dial pipeline, not the audio leg, so you will not hear your agent on a mock call.
• Live key ("telephony": "platform"): nothing originates in-request. The 202 returns state: "scheduled", the origination loop dials on your default telephony account as paid platform test-call minutes, and the destination must be an OTP-verified number you control. Live test calls are volume-capped per tenant per UTC day (test_call_cap_exceeded); mock test calls never draw the cap down.

What test mode does not skip

The compliance floor runs on every call through every entry point, test keys included: the AI-disclosure opener, internal-DNC suppression, and the platform kill switches. A configured live phone call durably records a contact’s opt-out before it closes. The synchronous mock test-call path does not enter the audio leg or exercise contact-bound tools, so test mode removes the carrier and that tool exercise, never the rules; a refusal like contact_not_dialable raised by a floor control behaves identically under a test key. Usage metering also still applies where the docs say it does; mock telephony simply never generates billable telephony usage.

Where test mode fits your pipeline

Build the tenant-facing parts of your integration against a test key first: agent creation, contact import, scrub runs, campaign create and launch, and webhook consumption. Use a configured live phone call to exercise the supported contact-bound tools; calendar actions require an active direct Google Calendar connection. Agent publishing requires the same scripted golden-suite release check in test and live modes: request it for the exact draft, wait for the deployment’s release worker, then publish only after it passes. The current scripted stand-in is not a live-provider or carrier evaluation. The deterministic digit map gives you fixture-quality outcomes in CI without a single real call. When you move to a live key, the only things that change are the telephony plane (your verified Twilio subaccount) and the gates that production arms: the executed Production Services Order, payment, BYO carrier verification, and staff’s reviewed fresh-step-up/dual-control promotion. See the Quickstart for the five-step version of this loop.