Programmable Voice DSL Reference

When you point one of your Devotel phone numbers (DIDs) at an HTTPS answer URL, Orbit turns that DID into a fully programmable inbound call — the Twilio voiceUrl / Vonage answer_url model. On every inbound call Orbit performs a server-side HTTP request to your URL with the call metadata and expects a JSON response describing what to do with the call. That JSON is a list of verbs — the programmable-voice DSL documented here. The verbs your answer_url returns are parsed, validated, and sanitised by sanitizeDslVerbs (apps/api/src/routes/jambonz/voice-dsl-executor.ts) — that function is the source of truth for this contract. The webhook inbound-route handler (buildWebhookVerbs in apps/api/src/routes/jambonz/verb-builder.ts) performs the server-side fetch to your URL and then hands the response body to sanitizeDslVerbs; the other build*Verbs handlers in that file build the platform-managed verb sequences for the non-webhook route types (agent, queue, voicemail, …). The verb shape is pinned as the VoiceDslVerb OpenAPI component (apps/api/src/lib/openapi-schemas.ts).

Outbound calls always terminate through the Devotel softswitch. Every dial verb is routed through Devotel’s wholesale softswitch trunk. You cannot select an arbitrary carrier, Telnyx Call Control, or DIDWW for the outbound leg — any carrier-selection field you return is ignored. Quality, STIR/SHAKEN signing, and PSAP routing are owned by Devotel.

Architecture: JSON verbs, not a VXML server

If you are coming from Twilio TwiML or raw VoiceXML, the mental model carries over with one difference: Orbit does not serve a VXML document to the voice engine. jambonz, the engine under Orbit, consumes the verbs as structured JSON, so your answer_url is the VXML authoring surface: it decides what happens next on every call, and the JSON verb list you return is the call-control document. Orbit validates and sanitises that document, then hands it to the engine exactly as a VXML interpreter would hand a parsed document to a browser. Scripting, branching, and loops live in your answer_url code (any language that can serve HTTPS JSON), not in a document grammar. The mapping is close to one-to-one. A classic VXML menu:

<?xml version="1.0" encoding="UTF-8"?>
<vxml version="2.1">
  <form>
    <field name="menu">
      <prompt>
        Press 1 for sales. Press 2 for support.
      </prompt>
      <grammar type="application/x-dtmf" mode="dtmf" root="MENU">
        <rule id="MENU">
          <item>1</item>
          <item>2</item>
        </rule>
      </grammar>
      <filled>
        <submit next="https://app.example.com/voice/menu"
                namelist="menu" method="post"/>
      </filled>
    </field>
  </form>
</vxml>

is this verb list in Orbit:

[
  { "verb": "say", "text": "Press 1 for sales. Press 2 for support." },
  {
    "verb": "gather",
    "input": ["digits"],
    "numDigits": 1,
    "timeout": 5,
    "actionHook": "https://app.example.com/voice/menu"
  }
]

<prompt> maps to say (or play for a hosted audio file), the DTMF grammar to gather with input: ["digits"] and numDigits, and <submit next=…> to actionHook, the URL that receives the collected digit and returns the next verb list. There is no XML to maintain, host, or version: the same serverless function or controller action that would render a VXML document returns JSON instead. The field-by-field correspondence for every verb is in the VoiceXML mappings table below.

The request Orbit POSTs to your answer_url

On each inbound call, Orbit sends an HTTP request to your configured URL. The default method is POST with a JSON body; if you configured GET, the same fields arrive as query-string parameters.

{
  "callSid": "call_01HZX...",
  "from": "+14155550123",
  "to": "+442071234567",
  "dialedE164": "+442071234567",
  "routeId": "route_01HZX...",
  "organizationId": "org_01HZX..."
}

Field	Type	Description
`callSid`	string	Unique per-call identifier. Stable for the life of the call.
`from`	string \| null	Caller’s E.164 number, or `null` when withheld.
`to`	string	The dialed E.164 number (your DID). Alias of `dialedE164`.
`dialedE164`	string	The dialed E.164 number (your DID).
`routeId`	string	The inbound-route record that pointed this DID at your URL.
`organizationId`	string	Your Orbit organization ID.

Verifying the request came from Orbit

When your inbound route has a signing secret configured, Orbit signs every request to your answer_url with HMAC-SHA256 so you can confirm it genuinely came from Orbit and was not forged by someone who learned your URL — the Twilio X-Twilio-Signature / Vonage answer_url JWT parity. Two headers carry the signature:

Header	Description
`X-Devotel-Timestamp`	Unix timestamp (seconds) when Orbit signed the request. Use it for replay protection.
`X-Devotel-Signature`	`sha256=<hex>` — the HMAC-SHA256, hex-encoded, of the signed content described below, keyed by your route’s signing secret.

Routes provisioned without a signing secret receive unsigned requests (neither header is present), so signing is opt-in and adding a secret never breaks an existing integration. The signed content is the timestamp, a literal ., and the exact request payload Orbit put on the wire:

POST — <X-Devotel-Timestamp>.<raw_request_body>, where the raw body is the exact JSON byte-for-byte as received. Hash the raw bytes; do not re-serialize the parsed JSON, or key-order and whitespace differences will make the signature mismatch.
GET — <X-Devotel-Timestamp>.<raw_query_string>, where the query string is exactly what Orbit appended to your URL (everything after ?, without the leading ?).

To verify:

Read X-Devotel-Timestamp and reject the request if it is older than a few minutes (for example, 5 minutes) to bound replay.
Compute expected = "sha256=" + HMAC_SHA256(secret, "<timestamp>.<payload>") as hex, using the raw body (POST) or raw query string (GET) as payload.
Compare expected against X-Devotel-Signature with a timing-safe comparison and reject on mismatch.

import crypto from 'node:crypto';

// `payload` is the raw request body (POST) or the raw query string (GET).
function verifyAnswerUrlRequest(payload, timestamp, signature, secret) {
  if (!timestamp || !signature) return false;

  // Replay protection: reject signatures older than 5 minutes.
  const ageSec = Math.floor(Date.now() / 1000) - Number(timestamp);
  if (!Number.isFinite(ageSec) || ageSec < 0 || ageSec > 5 * 60) return false;

  const expected =
    'sha256=' +
    crypto
      .createHmac('sha256', secret)
      .update(`${timestamp}.${payload}`, 'utf-8')
      .digest('hex');

  const expectedBuf = Buffer.from(expected);
  const signatureBuf = Buffer.from(signature);
  return (
    expectedBuf.length === signatureBuf.length &&
    crypto.timingSafeEqual(expectedBuf, signatureBuf)
  );
}

// In your answer_url handler (Express, using the raw body):
app.post('/voice/answer', express.raw({ type: '*/*' }), (req, res) => {
  const ok = verifyAnswerUrlRequest(
    req.body.toString('utf-8'), // raw POST body bytes
    req.headers['x-devotel-timestamp'],
    req.headers['x-devotel-signature'],
    'your_route_signing_secret',
  );
  if (!ok) return res.status(401).json({ error: 'Invalid signature' });

  const call = JSON.parse(req.body.toString('utf-8'));
  // Return your verb list...
  res.json({ verbs: [{ verb: 'say', text: 'Thanks for calling.' }] });
});

This answer_url signature is a separate scheme from the customer-webhook HMAC documented in Webhook Security. Both use HMAC-SHA256 keyed on a per-resource secret, but the answer_url request carries the timestamp in its own X-Devotel-Timestamp header and a sha256=<hex> value in X-Devotel-Signature, rather than the combined t=<unix>,v1=<hex> encoding used for webhook deliveries. Verify each with the scheme documented for it.

The response your answer_url returns

Respond with Content-Type: application/json and either an envelope or a bare array of verbs:

{
  "verbs": [
    { "verb": "say", "text": "Thanks for calling Acme." },
    { "verb": "dial", "target": [{ "type": "phone", "number": "+14155550123" }] }
  ]
}

A bare array is also accepted:

[
  { "verb": "say", "text": "Thanks for calling Acme." },
  { "verb": "hangup" }
]

The verbs run top-to-bottom. If your URL times out (default 5s, hard cap 10s), returns a non-2xx status, returns non-JSON, or returns an empty / malformed array, Orbit emits the route’s configured fallback verbs so the caller never lands on dead air.

Verbs

Each verb object is discriminated by its verb field.

`say`

Text-to-speech playback to the caller.

{ "verb": "say", "text": "Your call is important to us." }

Field	Type	Description
`text`	string	The text to synthesize and play.

`play`

Play a pre-recorded audio file. The URL must be https:// and is SSRF-validated at configuration time.

{ "verb": "play", "url": "https://cdn.example.com/greeting.wav" }

Field	Type	Description
`url`	string (https URI)	The audio file to stream to the caller.

`gather`

Collect DTMF and/or speech input from the caller. This is also the IVR-menu primitive: play your prompt with a preceding say (or play), then branch on the collected digit in the verb list you return from actionHook.

{
  "verb": "gather",
  "input": ["digits"],
  "numDigits": 1,
  "timeout": 10,
  "actionHook": "https://app.example.com/voice/ivr-step"
}

Field	Type	Description
`input`	string[]	Collection modes: `"digits"`, `"speech"`, or both.
`numDigits`	integer	Stop collecting after this many DTMF digits.
`timeout`	integer	Seconds to wait for input before falling through.
`actionHook`	string (https URI)	URL Orbit POSTs the collected input to; returns the next verb list.

`dial`

Bridge the caller to an outbound leg. Routed exclusively through the Devotel softswitch trunk — you cannot select a carrier.

{
  "verb": "dial",
  "callerId": "+442071234567",
  "timeout": 30,
  "target": [{ "type": "phone", "number": "+14155550123" }]
}

Field	Type	Description
`callerId`	string	Caller ID presented on the outbound leg. Must be a valid E.164 number; a missing or malformed value is dropped and Orbit applies a safe default (the dialed DID). The presented number is signed and attested (STIR/SHAKEN) by Devotel on the outbound leg.
`target`	object[]	Destinations to dial. Any carrier-selection field is ignored — termination is Devotel-owned.
`timeout`	integer	Seconds to ring before treating the leg as no-answer.

`record`

Capture the caller’s audio to a single recording file — the file-capture primitive (e.g. for a voicemail, a spoken message, or a survey answer). It records the current leg until the caller presses finishOnKey or maxLength seconds elapse, then POSTs the recording metadata to your actionHook. You are responsible for the consent this capture requires — see the consent note below.

{
  "verb": "record",
  "maxLength": 60,
  "finishOnKey": "#",
  "playBeep": true,
  "actionHook": "https://app.example.com/voice/recording-done"
}

Field	Type	Description
`maxLength`	integer	Maximum recording length in seconds before capture stops.
`finishOnKey`	string	DTMF key that ends the recording early (e.g. `"#"`).
`playBeep`	boolean	Play a short beep to the caller before recording begins.
`actionHook`	string (https URI)	URL Orbit POSTs the finished recording metadata to; returns the next verb list.

Consent for the record verb is your responsibility. A record verb returned from your answer_url is passed through to the call as-is — Orbit does not apply its recording-consent gate to it. That gate governs only Orbit-managed capture: route-level recording (recording_mode) and the platform voicemail flow. When your answer_url drives the call, you own the flow and the compliance obligation. Play any disclosure your jurisdiction requires — for example, US all-party-consent states or EU two-party consent regimes — before you return the record verb.

Recording the whole call is a route setting, not a DSL toggle. To record an entire bridged call, set the inbound route’s recording_mode (all or inbound) — Orbit then records both/inbound legs through the Devotel SIPREC server for the life of the call. There is no boolean record start/stop switch in the DSL: a record field set to true or false is not consumed by the engine and is ignored. Use the record verb above only to capture a discrete clip to a file.

`enqueue`

Park the caller in a named queue (e.g. for ACD / contact-center routing).

{ "verb": "enqueue", "queue": "support" }

Field	Type	Description
`queue`	string	The queue name to park the caller in.

`transfer`

Hand the call off to another inbound route or destination.

{ "verb": "transfer", "destination": "+442071234999" }

Field	Type	Description
`destination`	string	The route, extension, or E.164 number to transfer to.

Like dial, a transfer to a PSTN number terminates through the Devotel softswitch trunk — emergency short codes and blocked-prefix destinations are rejected, and the caller hears your fallback instead.

`hangup`

End the call. Optionally supply a SIP reason surfaced in carrier CDRs.

{ "verb": "hangup", "reason": "Caller served" }

Field	Type	Description
`reason`	string	Optional human-readable hangup reason.

`listen`

Fork the live, bidirectional call audio to your own WebSocket endpoint for custom transcription, voice-AI, or analytics — the Twilio Media Streams / Telnyx fork model. Orbit opens a secure WebSocket (wss://) to your url and streams raw audio frames for the duration of the call. The endpoint must be a public host: it is SSRF-validated at admission, so a private or internal address is rejected and the verb is dropped.

{
  "verb": "listen",
  "url": "wss://stream.example.com/calls",
  "mixType": "stereo",
  "sampleRate": 16000,
  "metadata": { "yourCallRef": "abc-123" },
  "bidirectionalAudio": { "enabled": true }
}

Field	Type	Description
`url`	string (wss URI)	Your WebSocket endpoint. Must be `wss://` — call audio is never sent over a plaintext socket.
`mixType`	string	`mono` (default), `stereo` (caller and far-end on separate channels), or `mixed`.
`sampleRate`	integer	PCM sample rate: `8000`, `16000`, `24000`, or `48000`.
`metadata`	object	Arbitrary JSON sent as the first WebSocket frame so you can correlate the socket to the call.
`bidirectionalAudio`	object	Set `{ "enabled": true }` to stream audio back over the same socket and play it into the caller’s leg (voice-AI / TTS).
`playBeep`	boolean	Play a short beep to the caller before forking begins.
`wsAuth`	object	`{ "username", "password" }` HTTP basic auth presented on the WebSocket upgrade.

listen forks media on the existing call leg — it never originates or terminates a call. Bidirectional audio is injected back into the same leg, so it does not create an outbound carrier leg and is unaffected by the softswitch-termination rule that governs dial.

VoiceXML mappings

For every construct, the verb you return and the VoiceXML element it replaces. Use this table when you port an existing VXML document.

VoiceXML construct	Orbit DSL equivalent
`<say>` / `<prompt>` (TTS)	`say` with `text`
`<audio src="…">`	`play` with `url`
DTMF `<grammar>` + `<field>`	`gather` with `input: ["digits"]`, `numDigits`, `timeout`
`<submit next="…">`	`actionHook` on `gather` or `record` (your handler returns the next verb list)
`<transfer dest="tel:…">`	`dial` with `target: [{ "type": "phone", "number": "…" }]`
`<record>` + `<submit>`	`record` with `maxLength`, `finishOnKey`, `playBeep`, `actionHook`
`<exit />` / `<disconnect />`	`hangup`
Server-side branching (`<if>` / `<goto>` in the document)	Branching in your answer_url code: read the POSTed `digits` and return the next verb list
`<subdialog>`	A second `actionHook` round-trip
Audio fork / media stream (not VXML-native)	`listen` with a `wss://` `url`

The constructs Orbit manages for you, and that you therefore never emit, are listed in Reserved verbs below. The canonical IVR: “press 1 for sales, press 2 for support.” First the classic two-document VXML form, then the same flow in Orbit. Entry document (what a VXML server would serve on answer):

<?xml version="1.0" encoding="UTF-8"?>
<vxml version="2.1">
  <form>
    <field name="menu">
      <prompt>
        Welcome to Acme. Press 1 for sales. Press 2 for support.
      </prompt>
      <grammar type="application/x-dtmf" mode="dtmf" root="MENU">
        <rule id="MENU">
          <item>1</item>
          <item>2</item>
        </rule>
      </grammar>
      <noinput>
        <prompt>I did not hear anything.</prompt>
        <reprompt/>
      </noinput>
      <filled>
        <submit next="https://app.example.com/voice/menu"
                namelist="menu" method="post"/>
      </filled>
    </field>
  </form>
</vxml>

The same entry point as Orbit verbs (what your answer_url returns):

[
  { "verb": "say", "text": "Welcome to Acme. Press 1 for sales. Press 2 for support." },
  {
    "verb": "gather",
    "input": ["digits"],
    "numDigits": 1,
    "timeout": 5,
    "actionHook": "https://app.example.com/voice/menu"
  },
  { "verb": "say", "text": "We did not receive any input. Goodbye." },
  { "verb": "hangup" }
]

Line by line:

VXML line	Verb
`<prompt>Welcome to Acme. …`	`say`
`<grammar … mode="dtmf">` + `<rule>` items 1, 2	`gather` with `numDigits: 1`; the allowed digits are validated by your actionHook, which simply ignores any other key
`<submit next="…/voice/menu">`	`actionHook`
`<noinput>` + `<reprompt/>`	The tail of the list: when `gather` times out with no digit, execution falls through to the next verbs (the apology `say` then `hangup`). To reprompt instead, return the same list again from your actionHook when no digit arrives.

Branch document (what the VXML server would serve after <submit>; in Orbit, what https://app.example.com/voice/menu returns). Your handler reads the POSTed digits field and returns the matching verb list:

[
  { "verb": "say", "text": "Connecting you to sales." },
  {
    "verb": "dial",
    "timeout": 30,
    "target": [{ "type": "phone", "number": "+14155550100" }]
  }
]

for digit 1, and the equivalent list pointing at your support line for digit 2. The dial verb terminates through the Devotel softswitch trunk; no carrier selection is possible or needed. The complete handler, including signature verification, is in Verifying the request came from Orbit; the response envelope is in The response your answer_url returns.

Copy-paste snippets

Both snippets below are the wire contract verbatim: Orbit sanitises the list and hands it to the engine, so the JSON is the executed call-control document — there is no intermediate VXML render step to inspect. Each snippet also shows the classic VoiceXML document it replaces, for readers porting an existing VXML app; the construct-by-construct correspondence is in VoiceXML mappings.

Outbound appointment reminder

Originate the call with POST /calls, passing your answer_url exactly as you would for inbound. This is the same contract as Twilio’s POST /Calls with a Url.

curl -X POST https://api.orbit.devotel.io/api/v1/calls \
  -H "X-API-Key: $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "+14155550182",
    "from": "+14155550100",
    "answer_url": "https://app.example.com/voice/reminder"
  }'

The answer_url returns:

[
  {
    "verb": "say",
    "text": "Hello, this is a reminder from Acme Clinic. You have an appointment tomorrow at 2:30 PM. Press 1 to confirm, or press 2 to cancel."
  },
  {
    "verb": "gather",
    "input": ["digits"],
    "numDigits": 1,
    "timeout": 5,
    "actionHook": "https://app.example.com/voice/reminder-response"
  },
  { "verb": "hangup" }
]

The VoiceXML document this flow replaces (for reference — Orbit executes the JSON above, it never renders this document):

<?xml version="1.0" encoding="UTF-8"?>
<vxml version="2.1">
  <form>
    <prompt>
      Hello, this is a reminder from Acme Clinic. You have an appointment
      tomorrow at 2:30 PM. Press 1 to confirm, or press 2 to cancel.
    </prompt>
    <field name="resp">
      <grammar type="application/x-dtmf" mode="dtmf" root="RESP">
        <rule id="RESP">
          <item>1</item>
          <item>2</item>
        </rule>
      </grammar>
      <filled>
        <submit next="https://app.example.com/voice/reminder-response"
                namelist="resp" method="post"/>
      </filled>
    </field>
  </form>
</vxml>

Your actionHook handler records the digit (1 = confirmed, 2 = cancelled, absent = no answer) and returns a closing say plus hangup. In sandbox mode the call resolves completed without touching a carrier, so you can exercise the full round-trip for free; see Test your flow without live minutes.

Record then transcribe a voicemail

Capture the message with record, then fork live audio to your transcription worker with listen. The recording metadata POSTed to your actionHook carries the recording URL; the wss:// stream carries the audio frames your worker transcribes.

[
  { "verb": "say", "text": "You have reached Acme. We are unavailable. Please leave a message after the tone, then press pound." },
  {
    "verb": "record",
    "maxLength": 120,
    "finishOnKey": "#",
    "playBeep": true,
    "actionHook": "https://app.example.com/voice/voicemail-saved"
  },
  {
    "verb": "listen",
    "url": "wss://transcribe.example.com/stream",
    "mixType": "mono",
    "sampleRate": 16000
  },
  { "verb": "hangup" }
]

The VoiceXML document this flow replaces (for reference — Orbit executes the JSON above, it never renders this document):

<?xml version="1.0" encoding="UTF-8"?>
<vxml version="2.1">
  <form>
    <prompt>
      You have reached Acme. We are unavailable. Please leave a message
      after the tone, then press pound.
    </prompt>
    <record maxtime="120s" dtmfterm="#" beep="true" name="msg"/>
    <submit next="https://app.example.com/voice/voicemail-saved"
            namelist="msg" method="post"/>
  </form>
</vxml>

Both URLs are validated before the engine uses them: actionHook must be https:// on a public host, and listen must be wss:// on a public host. Anything else (an internal address, plaintext ws://) is dropped so the call degrades safely instead of failing. Remember that consent for record is yours to provide; see the consent warning under record above.

Test your flow without live minutes

The Sandbox and magic numbers simulator keys every outcome on the trailing digit of the destination number, so you can walk a whole flow with no carrier and no charge.

Create an inbound route that points one of your sandbox DIDs at your answer_url, and use a sandbox API key (prefix dv_test_sk_*).
Place a sandbox call to the DID. The call never reaches a carrier and deducts no balance.
Exercise the failure paths by calling the magic numbers instead: trailing 9 maps to no-answer and 8 to busy in the simulator’s catalog, so your no-input and no-answer branch logic gets real traffic.
Assert on your side: your answer_url log shows the POST from Orbit with callSid, from, and to, and your actionHook receives the DTMF digits you sent.

Sandbox voice calls resolve completed today regardless of the trailing digit; the digit table is the simulator’s reference catalog, not live voice behaviour. There is no sandbox DTMF sender: to drive the actionHook branches, answer a sandbox call with a SIP softphone pointed at your sandbox DID, or return the branch verb lists directly from your answer_url while developing.

Limits and pitfalls

Answer-URL budget: default timeout 5 seconds, hard cap 10 seconds, on every fetch (first answer and each actionHook round-trip). A slow endpoint means the fallback verbs run instead of your flow; keep prompts pre-rendered and databases warm.
No loops in the document: there is no loop verb. Re-prompts and retries are your code’s job: return the same verb list from your actionHook, and cap the attempts yourself (for example, three gather round-trips, then hangup). Also cap chained actionHook hops: each hop is a network round-trip billed against the caller’s patience.
Asynchronous verbs: gather and record pause execution until input or timeout; nothing after them runs until they complete. Whatever follows a gather is the no-input path, as in the IVR example above.
An empty or malformed response runs the fallback: returning [], non-JSON, or a non-2xx never produces dead air; the route’s fallback (safe-default apology, voicemail, or decline) runs instead.
Reserved verbs are dropped: conference and config returned from your answer_url are silently removed; see Reserved verbs.
Caller ID on dial: a callerId that is not a syntactically valid E.164 number is dropped and the dialed DID is presented instead; ownership and STIR/SHAKEN attestation happen on the softswitch leg.
Hard rejections replace the whole sequence: a dial or transfer to an emergency short code or a blocked prefix does not drop only that verb; the caller hears a polite refusal and the call ends, so a bad number cannot slip past a good prompt.
dial exits through the Devotel softswitch only (see the note at the top of this page): carrier-selection fields you return are ignored, SIP-URI targets are rejected, and emergency or blocked-prefix destinations are refused.
listen needs a public wss:// host and forks the existing leg only; it never originates or terminates a call.

Reserved verbs

Two verbs are managed by Orbit and cannot be returned from your answer_url:

conference — joining a caller into a named conference room. Rooms are created and named by the platform (conference routes, call park, supervisor monitoring), so accepting a room name from a webhook would let one call bridge into another tenant’s or a supervisor’s room. Configure conference routes in the dashboard instead.
config — changing in-call engine settings such as pausing or resuming recording. Recording is governed by your route’s recording and consent settings, not by the verb list.

If your answer_url returns either verb, Orbit drops it and continues with the rest of your verb list. Everything you need for a normal call flow is covered by the verbs above.

Failure handling

Orbit fails soft. If your answer_url is slow, unreachable, returns a non-2xx, or returns a malformed body, the configured fallback runs instead — one of:

safe-default — a short apology prompt then hangup.
voicemail — defer to the route’s voicemail configuration.
decline — reject the call with a SIP 603 Decline.

The caller is never left on dead air, and the categorical failure reason is logged for your route analytics without leaking operator topology.

Reference

Programmable Voice DSL: verbs for answer_url call control

Programmable Voice DSL Reference

Architecture: JSON verbs, not a VXML server

The request Orbit POSTs to your answer_url

Verifying the request came from Orbit

The response your answer_url returns

Verbs

`say`

`play`

`gather`

`dial`

`record`

`enqueue`

`transfer`

`hangup`

`listen`

VoiceXML mappings

End-to-end example: IVR menu, VXML translated to the DSL

Copy-paste snippets

Outbound appointment reminder

Record then transcribe a voicemail

Test your flow without live minutes

Limits and pitfalls

Reserved verbs

Failure handling

​Programmable Voice DSL Reference

​Architecture: JSON verbs, not a VXML server

​The request Orbit POSTs to your answer_url

​Verifying the request came from Orbit

​The response your answer_url returns

​Verbs

​say

​play

​gather

​dial

​record

​enqueue

​transfer

​hangup

​listen

​VoiceXML mappings

​End-to-end example: IVR menu, VXML translated to the DSL

​Copy-paste snippets

​Outbound appointment reminder

​Record then transcribe a voicemail

​Test your flow without live minutes

​Limits and pitfalls

​Reserved verbs

​Failure handling

Programmable Voice DSL Reference

Architecture: JSON verbs, not a VXML server

The request Orbit POSTs to your answer_url

Verifying the request came from Orbit

The response your answer_url returns

Verbs

`say`

`play`

`gather`

`dial`

`record`

`enqueue`

`transfer`

`hangup`

`listen`

VoiceXML mappings

End-to-end example: IVR menu, VXML translated to the DSL

Copy-paste snippets

Outbound appointment reminder

Record then transcribe a voicemail

Test your flow without live minutes

Limits and pitfalls

Reserved verbs

Failure handling