# Glossary

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

## Voice callback events

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.

### ICE — Incoming Call Event

Fired when a phone call arrives at one of your Sinch phone numbers. Your function responds with [SVAML](#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.

### ACE — Answered Call Event

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.

### PIE — Prompt Input Event

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.

### DICE — Disconnected Call Event

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

### Typical lifecycle


```
Inbound call:   ICE → (optional PIE loop for menus) → DICE
Outbound call:  ACE → (optional PIE loop)            → DICE
```

## SVAML — Sinch Voice Application Markup Language

A 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](/docs/functions/reference/svaml-cheatsheet) for the most-used actions, or the [full SVAML spec on developers.sinch.com](/docs/voice/api-reference/svaml/) for every action and option.

## Voice App

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.

## Conversation App

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.

## Sinch Dashboard

The web-based control surface for your Sinch account, at [dashboard.sinch.com](https://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.

## Project (Project ID)

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](https://dashboard.sinch.com) under Settings.

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

## FunctionContext

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](/docs/functions/functions/concepts/context-object) for the full tour.

## Handler

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 `status` and it's available at `POST /status`. (Node.) Or add a controller action in C#.


See [handlers](/docs/functions/functions/concepts/handlers) for how the mapping works.

## Template

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`.

## Tunnel

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.

## Dev vs Prod runtime package

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.

## sinch.json

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`.

## Assets

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).