Architecture

This page walks through the moving parts so you have a mental model of where your code sits and what runs where.

The CLI uploads your source and configuration to the Sinch Functions Platform. From there, the platform builds your function, runs it, and updates any callback URLs on your Voice or Conversation apps so inbound traffic reaches the new version.

1. You run sinch functions deploy from your project directory.
2. The CLI validates your project:
   • Node: typecheck, bundle with tsup, smoke-test.
   • C#: dotnet build, health-check locally.
3. The CLI packages the project into a zip and uploads it to the Sinch Functions Platform.
4. The platform builds and rolls out your function. If an identical build already exists, the build step is skipped and the existing artifact is reused.
5. Your function comes up at https://<name>.fn.sinch.com (or https://<name>.private.fn.sinch.com if deployed private).
6. If your project's sinch.json declares a Voice service or Conversation App, the CLI updates its webhook/callback URL to point at the new function.

1. A caller dials your Sinch phone number.
2. Sinch's voice platform receives the call and looks up the Voice service assigned to that number.
3. The service sends a call.incoming event to your function's voiceWebhook export.
4. Your function runs, builds a commands response, returns it.
5. Sinch runs the commands and controls the call accordingly — plays audio, runs menus, dials legs, records, etc.
6. If a menu doesn't resolve every branch itself, Sinch sends a call.menu event when it completes. You respond with the next set of commands.
7. When the call ends, Sinch sends a call.hangup (or call.failed) event. Your function can log or clean up.

Functions still wired to a legacy Voice API v1 application receive the older ICE/ACE/PIE/DICE callbacks instead.

See voice-callbacks for the callback lifecycle in detail.

1. A user sends an SMS or WhatsApp message to a number assigned to your Conversation App.
2. The Conversation platform posts a webhook to your function's URL.
3. Your function runs, decides what to do, and optionally sends a reply via context.conversation.messages.send(...).

1. The CLI starts your function locally — hot-reloading via tsup watch (Node) or dotnet watch (C#).
2. It opens a tunnel (Cloudflare Tunnel) that gives your local process a public URL.
3. It optionally updates your Voice service's webhook URL to the tunnel URL so Sinch can reach your laptop directly.
4. When a real call hits the number, Sinch calls your laptop, and you see requests in real time via sinch functions logs.
5. Stop the dev server and the CLI reverts any callback URLs it touched.

This means you can test against real Sinch traffic from your laptop, with no deploy loop.

See configuration-secrets for the full story of how each layer is resolved.

Deployed functions run in an isolated, managed runtime environment. The platform provides:

• Cache — persistent and shared across invocations
• Blob storage — durable and backed up
• SQLite database — with automatic durable replication, so it survives restarts
• Per-function subdomain — https://<name>.fn.sinch.com (https://<name>.private.fn.sinch.com when private)
• Auto-scaling based on request volume
• Structured logging streamed via sinch functions logs
• Pre-initialized SDK clients for Voice, Conversation, SMS, Numbers (and Verification in C#) when the right environment variables are set

You don't see any of this infrastructure from your code. You write a handler, the runtime takes care of the rest.