Skip to content
Last updated

What are Sinch Functions and the CLI?

What Sinch Functions is (30 seconds)

Sinch is a communications platform. Businesses use Sinch APIs to:

  • Make and receive phone calls (PSTN, SIP)
  • Send and receive SMS, MMS, WhatsApp, Messenger, Viber, RCS
  • Send faxes
  • Verify users (OTP, flashcall, data verification)
  • Route calls through SIP trunks

You, the developer, interact with Sinch in two ways: REST APIs and the Sinch CLI.

What the Sinch CLI is

The sinch command-line tool wraps Sinch REST APIs into fast developer workflows. It does three things:

  1. Manage Sinch resources from your terminal. Rent phone numbers, configure voice apps, manage SIP trunks, send faxes, send messages, store secrets.
  2. Build and deploy Sinch Functions. Scaffold a function from a template, run it locally with hot reload, deploy it to production.
  3. Keep your credentials safe. API keys are stored in the OS keychain (not in a dotfile), so nothing leaks into shell history or version control.

Install it, log in once, and every Sinch workflow is a command away.

What Sinch Functions are

Sinch Functions are serverless compute for voice and messaging. Instead of standing up a server to handle an incoming call or SMS, you write a function:

  • A call comes in → Sinch sends a callback to your function → you return call-control instructions (SVAML).
  • An SMS arrives → Sinch posts a webhook → your function replies, stores data, or fans out to other APIs.
  • You want a custom HTTP endpoint → you export a handler, Sinch exposes it at a URL.

Sinch runs your code in isolated containers, auto-scales to traffic, and deploys in seconds. No infrastructure to manage.

Why use Functions instead of your own server?

  • No infrastructure. No containers, no load balancers, no capacity planning.
  • Fast deploys. sinch functions deploy packages and ships in under a minute.
  • SDK clients pre-wired. context.voice, context.conversation, context.sms, context.numbers are ready to use — no credential management in your code.
  • Batteries included. Cache, blob storage, SQLite database, environment secrets — all injected by the runtime.
  • Local development that feels like production. sinch functions dev runs your function on your laptop with a public tunnel so Sinch can reach it.

How the CLI and Functions relate

The CLI is a general Sinch developer tool. Functions is a serverless product built on top of Sinch, and the CLI happens to be the primary interface for it. You can use one without the other:

  • CLI without Functions: rent a number, configure its SMS webhook to point at an existing server you already run. Done.
  • Functions without full CLI: write and deploy an IVR, never touch sinch numbers or sinch fax.

Think of it this way:

  • The CLI is how you work.
  • Functions are what you build when you want Sinch to host your code.

Runtime mental model

The Functions runtime is designed to feel like a framework you already know:

  • Node.js runtime is effectively Express with conventions. You export handlers, Sinch maps URL paths to them, you get a request and return a response.
  • C# runtime is ASP.NET MVC with controllers. You extend a base controller, override the methods you care about, and the runtime DI container wires up services and SDK clients.

That's it. The rest of the docs are conventions, the SVAML builder APIs, and where to find the context object.

Where to go next