Glossary

The Sinch platform uses a handful of terms that are not obvious at first. Here's what each one means.

When something happens to a call on the Sinch network, the platform sends an HTTP callback to your Function's voiceWebhook export. Every event is named call.<something>, and onCall (Node) / a set of On* virtuals on SinchVoiceController (C#) route them to the right handler by lifecycle stage.

Fired when a phone call arrives at one of your Sinch phone numbers. Your function responds with SVAML to decide what happens next: play a message, dial another number, run a menu, record, etc.

incoming is where most Functions do their work.

Fired when an outbound leg you dialled is answered. Use this to start doing something once the other party picks up — play a message, run an IVR on the callee.

Fired when a menu interaction completes without every branch resolving on the platform. The caller pressed a DTMF digit (or said something that was recognized), and you get the result and respond with the next set of commands.

Fired when the call ends. Informational only — use it for logging, billing, cleanup.

Inbound call:   call.incoming → (optional call.menu loop) → call.hangup
Outbound call:  call.answered → (optional call.menu loop)  → call.hangup

Voice API v1 (legacy). Functions still wired to a v1 Voice Application use four callbacks named ICE, ACE, PIE and DICE instead — the SDK for them lives at context.voice.v1. New functions build on Voice API v2 above.

A JSON format for controlling calls. When your Function responds to a voice event, it returns SVAML commands telling Sinch what to do: "say this message", "play this audio", "dial this number", "run this menu", and so on.

Both runtimes provide a fluent command builder so you never write raw JSON. dialPhone/DialPhone bridge a leg onto the live call and need one to bridge to — inside a handler's builder that's automatic, so a bare one-liner like this has to name it explicitly with liveLeg/LiveLeg:

• Node: commands().answer().say('Hello').dialPhone('+15551234567', { liveLeg: 'origin' }).build()
• C#: new CommandBuilder().Answer().Say("Hello").DialPhone("+15551234567", new BridgeToOptions { LiveLeg = "origin" }).Build()

See the SVAML cheat sheet for the most-used commands, or the full Voice API v2 spec on developers.sinch.com for every command and option.

The Voice API v2 entity that routes inbound calls to your function. A Voice service has:

• A service ID — the value a v2 function stores as VOICE_SERVICE_ID
• A service secret — used to verify the signature on webhooks it sends, once Sinch exposes it for the service
• Assigned phone numbers that route calls to it

When you deploy a Function that handles voice, the CLI can update the service's inbound webhook URL to point at your Function's new URL. That linking is managed via sinch.json in your project.

Voice App (legacy, Voice API v1). The older equivalent, authenticated with an application key + secret instead of a service ID, with callback URLs for ICE/ACE/PIE/DICE events.

The multi-channel messaging equivalent of a Voice App. A Conversation App has:

• An App ID
• Channel credentials (WhatsApp Business Account, Messenger page token, Viber credentials, etc.)
• Webhook URL — where Sinch posts incoming messages and delivery events

One Conversation App can handle many channels simultaneously. SMS, WhatsApp, Messenger, Viber, RCS, MMS all go through the same webhook.

The web-based control surface for your Sinch account, at dashboard.sinch.com. It's where you:

• Create and manage Projects
• Issue and rotate API keys
• Configure Voice Apps and Conversation Apps
• Buy, manage, and release phone numbers
• View usage, billing, and logs

The Sinch CLI is the terminal-side complement to the Dashboard — everything the CLI does goes through the same underlying APIs, so work done in either place shows up in the other.

The top-level tenant in your Sinch account. Everything — Voice Apps, Conversation Apps, phone numbers, API credentials — belongs to a Project. Find your Project ID in the Sinch Dashboard under Settings.

Most CLI commands need a Project ID to know which account to operate on; sinch auth login stores it for you.

The object your handler receives as its first parameter. It gives you cache, storage, config, logger, and pre-wired SDK clients for Voice, Conversation, SMS, and Numbers. Think of it as "the standard library of the Sinch runtime." See context-object for the full tour.

A function (Node) or controller method (C#) that Sinch invokes over HTTP.

• Voice callbacks (v2) all reach one voiceWebhook export, routed internally to incoming/answered/manage/completed by onCall. Voice callbacks (v1, legacy) map to specific handler names instead: ice, ace, pie, dice.
• Custom HTTP endpoints map by URL path — export a function named status and it's available at POST /status. (Node.) Or add a controller action in C#.

See handlers for how the mapping works.

A pre-built starting point for a Function. sinch templates list shows what's available; sinch functions init <template> scaffolds a new directory with working code. Examples include simple-voice-ivr, sms-autoresponder, and number-masking.

Templates are published by the Sinch team and fetched by the CLI on demand — you always get the latest versions when you run sinch templates list or sinch functions init.

A public URL that points to your local sinch functions dev process. Sinch can't reach localhost, so when you're developing, the CLI opens a Cloudflare Tunnel (or similar) that exposes your laptop to the internet for the duration of the session.

When sinch functions dev exits, the tunnel closes and any Voice App callback URLs the CLI touched are reverted.

The Function runtime has two flavors of each package:

• Dev package — what you develop against locally. Cache is in-memory, storage is the local filesystem, the database is a plain SQLite file.
• Prod package — swapped in at deploy time. Cache is persistent and shared across invocations, storage is durable cloud-backed, and the SQLite database is continuously backed up.

You never reference the prod package directly. The build pipeline handles the swap. Your code imports from the dev package and runs unchanged in production.

The project manifest for a Function. Defines its name, runtime, variables, template metadata, and (if the function handles voice or messaging) which Voice App or Conversation App it's bound to. The CLI reads this file when you run sinch functions dev and sinch functions deploy.

Secrets are not declared in sinch.json — they live in the OS keychain under the function name and are injected into the deployed runtime as environment variables. Manage them with sinch secrets add.

Files you ship alongside your code that the runtime can read at request time — prompts (WAV, MP3), JSON data, templates. Access them with context.assets('filename.wav') rather than fs.readFileSync (which won't find them in production).