Beta. Sinch Functions is currently in beta — you can build and deploy today, and the shape of the runtime may evolve during the beta period.
Serverless compute for voice, SMS, and messaging. Write a function, deploy it, and Sinch routes live traffic to your code. No infrastructure to run, no load balancers, no capacity planning.
The Sinch Voice API and Conversation API already do the hard parts — the telephony network, the WhatsApp Business integration, the number routing. What you still need is a place to put your business logic: the menu structure for your IVR, the reply behavior for your SMS bot, the routing rules for your number masking service.
Functions is that place. You deploy your code, the runtime gives it a public URL, and Sinch calls that URL whenever something happens on a call or a message. Your code runs in an isolated, managed runtime with a cache, a blob store, a SQLite database, and pre-wired SDK clients for the Sinch APIs.
| Use case | What it does |
|---|---|
| Voice IVR | Interactive menus with DTMF input and text-to-speech |
| SMS responder | Reply to inbound SMS with dynamic content |
| Call routing | Route calls based on caller, time, or external data |
| AI voice agent | Connect calls to a speech AI pipeline via ElevenLabs or similar |
| Number masking | Proxy calls between parties without exposing real numbers |
| Conversation bot | Handle WhatsApp, Messenger, SMS via the Conversation API |
| Custom HTTP API | Host internal endpoints alongside your voice/messaging logic |
Feature parity across both — same cache, storage, database, SDK clients. Pick the one your team already knows.
| Node.js | C# | |
|---|---|---|
| Language | TypeScript / JavaScript | C# / .NET 9+ |
| Package | @sinch/functions-runtime | Sinch.Functions.Runtime |
| Mental model | Like Express | Like ASP.NET MVC with controllers |
| Hot reload | Automatic on save | dotnet watch |
See handlers for the "it's just Express / it's just MVC" framing in detail.
You already know most of this if you've written a web service. The twist is where the HTTP requests come from — Sinch's voice platform sends callbacks when calls happen, the Conversation platform posts webhooks when messages arrive, and the runtime routes those to specific handlers in your code.
- Voice events →
ice,ace,pie,dicehandlers - Conversation events → a
ConversationController(or webhook handler) - Your own HTTP endpoints → any other named export (Node) or controller action (C#)
Get started:
- Quickstart — deploy an IVR from a template in five minutes
- Your first function — build one from scratch, no templates
- Local development — hot reload, tunneling, debugging
Concepts:
- Handlers — the runtime mental model (Express / ASP.NET MVC analogy)
- Voice callbacks — ICE/ACE/PIE/DICE lifecycle
- Context object — cache, storage, config, SDK clients
- Configuration & secrets — how variables and secrets flow
- Deployment — what
sinch functions deployactually does
Build something:
- Build an IVR — menu-driven inbound voice
- Build an SMS responder — multi-channel messaging bot
- Build an AI voice agent — ElevenLabs + SIP
- Route calls — time-based, caller ID, and custom routing
- Add a custom HTTP endpoint — expose REST alongside voice
- Use the cache — session storage and rate limiting
- Protect your function — Basic Auth for handlers
- Integrate the Operations API — monitoring, alerting, observability
Runtime guides:
- Node.js runtime / C# runtime — per-runtime reference