Skip to main content
Yotel has two environments on a single codebase + database. You switch by switching the API key’s prefix:
PrefixEnvironmentBehavior
yt_live_…LiveReal PSTN dialing, real charges, webhooks to your production URL.
yt_test_…TestSandbox: DB writes + webhooks fire, but no PSTN originate.

​
What changes in test mode

SurfaceLiveTest
POST /api/v1/campaignsCreates rowCreates row (identical)
POST /api/v1/leadsInserts leadInserts lead (identical)
POST /api/campaigns/{id}/startStarts dialer + originatesStarts dialer, no originate
Call recordingsReal audioNo recording created
WebhooksPOSTed to subscription’s urlPOSTed to test_url if set, else url
Rate limitsEnforcedEnforced (identical)
DND scrubEnforcedEnforced (identical)
Test mode is not a read-only mode — writes persist. Your sandbox campaigns + leads share the tenant’s database with production. Use distinct labels or a separate tenant if that bothers you.

​
Webhook subscription test_url

When creating a webhook subscription, you can optionally set test_url to a separate endpoint. Test-environment events POST there instead of the production url. Common pattern: 
url:      https://api.prod.mycrm.com/webhooks/yotel
test_url: https://webhook.site/abc-123
That way your prod integration isn’t polluted with test-mode events during development.

​
How webhooks indicate environment

Every webhook delivery’s data includes the originating call / campaign, which carries the environment pinned at dial time (via calls.dial_mode and related fields). To distinguish explicitly, add a custom header or inspect the key that triggered the event — we’ll add environment to the envelope in v1.1.

​
Switching a campaign between environments

You can’t. The environment is pinned to the key that created the campaign. To “convert” a test campaign to live: export its config + leads, create a new campaign with a live key, import. This is a deliberate guardrail. Bugs that silently promoted test actions to live would be regulatory (TRAI) + billing incidents.