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, Sinch sends an HTTP callback to your Function. There are four of them, and together they describe the call's lifecycle.
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, connect to another number, run a menu, record, bridge to SIP, etc.
ICE is where most Functions do their work.
Fired when an outbound call you initiated is answered. Use this to start doing something once the other party picks up — play a message, start a conference, run an IVR on the callee.
Fired when a menu interaction completes. The caller pressed a DTMF digit (or said something that was recognized), and the menu you started via SVAML returned a result. You get the result and respond with the next SVAML step.
Fired when the call ends. Informational only — use it for logging, billing, cleanup.
Inbound call: ICE → (optional PIE loop for menus) → DICE
Outbound call: ACE → (optional PIE loop) → DICEA JSON format for controlling calls. When your Function responds to an ICE callback, you return SVAML telling Sinch what to do: "say this message", "play this audio", "connect to this number", "run this menu", and so on.
Both runtimes provide fluent builders so you never write raw JSON:
- Node:
new IceSvamlBuilder().say('Hello').connectPstn('+15551234567').build() - C#:
new IceSvamletBuilder().Instructions.Say("Hello").Action.ConnectPstn("+15551234567").Build()
See the SVAML cheat sheet for the most-used actions, or the full SVAML spec on developers.sinch.com for every action and option.
A configuration entity in Sinch that owns your voice functionality. A Voice App has:
- An application key + secret (authentication)
- Callback URLs — where Sinch sends ICE, ACE, PIE, DICE events
- Assigned phone numbers that route calls to it
When you deploy a Function that handles voice, the CLI can update the Voice App's callback URL to point at your Function's new URL. That linking is managed via sinch.json in your project.
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 map to specific handler names:
ice,ace,pie,dice. - Custom HTTP endpoints map by URL path — export a function named
statusand it's available atPOST /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-responder, and ai-voice-agent.
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).