# sinch functions

Manage Sinch Functions — the full lifecycle from creation through deployment and operations.

## sinch functions init

Initialize a new function from a template. Downloads the template, prompts for variables and secrets, sets up the project directory, and installs dependencies.

**Syntax**

```sh
sinch functions init [template] [options]
```

Running this from a pipeline? See [CI/CD](/assets/ci-cd.2b77a2f80d1cc738bf7f659cc80e42f3edfce68a85ee69f318e05c7511c34d11.8a245974.md).

**Voice templates.** Every template in the `voice` category runs a Voice service picker, whether or not the template declares `VOICE_SERVICE_ID` itself. Pick an existing Voice API v2 service or create one, and init writes the id as `VOICE_SERVICE_ID` in `.env` (Node.js) or `appsettings.json` (C#); `sinch functions deploy` then points that service's inbound webhook at the deployed function. Skipping the picker leaves the value unset, and init prints the key to set later. No Voice Application Key or Secret is requested — that legacy pair is prompted for only by a template that names `VOICE_APPLICATION_KEY` among its variables.

`--non-interactive` never calls the picker (it never lists services from the API), so a voice template gets no `VOICE_SERVICE_ID` unless one is supplied with `--voice-service-id`. Without it, init omits the key and prints a warning instead of writing it blank.

**Options**

| Option | Description |
|  --- | --- |
| `[template]` | Template name to use (e.g., `simple-voice-ivr`). May also be given as `runtime/template-name` (e.g., `node/simple-voice-ivr`), the form printed by `sinch templates list` and `sinch templates show` — the prefix sets the runtime, and it is an error if it contradicts `--runtime`. |
| `--name <name>` | Function name (defaults to template name) |
| `--runtime <runtime>` | Runtime: `node` or `csharp`. Optional when `[template]` is given — the CLI infers the runtime from the template name and only prompts when no template arg is passed. If the same template exists for both runtimes, Node.js is used by default; pass `--runtime csharp` to override. |
| `--skip-install` | Skip `npm install` for Node.js projects |
| `--non-interactive` | Use defaults without prompting |
| `--voice-service-id <id>` | Voice v2 service to route inbound calls through (voice templates only). Required for a routed voice function in a non-interactive init; interactively it just pre-fills the picker's default. |


## sinch functions list

List all functions in the current project.

```sh
sinch functions list
```

## sinch functions deploy

Deploy the function in the current directory to production. Packages the source into a ZIP, reads configuration from `.env` (Node.js) or `appsettings.json` / `dotnet user-secrets` (C#), and submits a deployment job.

For C# functions, the CLI builds and health-checks locally before deploying. Secrets are pulled from the OS keychain automatically. An empty value in `.env` / `appsettings.json` also resolves from the CLI's own process environment before falling back to the keychain, so a caller that injects secrets straight into the deploy process (no on-disk secret store to read from) doesn't need one. After deployment, the CLI automatically updates your Voice callback URL or Conversation webhook if configured.

For Node.js functions, deploy stops before packaging if there is no `.env` file in the project directory — without one the deployed function has no configuration and will not run. Run [`sinch env init`](/assets/env.fe0cbe45123bf8e298e50a1a920e0bdb617c551c4b3bf9b10e7959a46aa55c77.63d64e7d.md) to recreate it. This is a hard error, not a warning, so `--force` does not bypass it.

On an interactive first deploy, the CLI asks whether to use a managed key for the function (default: yes) and saves the choice as `accessKey: "managed"` or `accessKey: "profile"` in `sinch.json`; use `--managed-keys` to select and persist managed keys without prompting. Existing `accessKey` values are reused without prompting, while `--non-interactive` and truthy `CI` use `profile` for the current deploy without adding the field.

Any warnings the API returns for the deployment (for example, about the managed key configuration) are printed after the deploy and included in the `--json` output.

**Syntax**

```sh
sinch functions deploy [options]
```

**Options**

| Option | Description |
|  --- | --- |
| `-n, --name <name>` | Override function name |
| `--no-wait` | Submit deployment and return immediately |
| `--non-interactive` | Use defaults without prompting |
| `--managed-keys` | Use and persist a managed access key |
| `--no-docs` | Skip documentation generation |
| `--public` | Deploy to the public namespace (internet-accessible) |
| `--force` | Deploy despite validation warnings without prompting |
| `--json` | Print the result as JSON and suppress progress output |
| `--private` | Deploy to private namespace (internal access only) |
| `--strict-audit` | Fail the deploy if the dependency audit finds anything at `--audit-level` |
| `--audit-level <level>` | Severity the dependency audit reports on: `low`, `moderate`, `high` (default), `critical` |


**Dependency audit**

Node functions are audited before upload. The CLI runs `npm audit --omit=dev` in the function directory and prints a one-line summary. It never blocks unless you pass `--strict-audit`, so an advisory feed outage cannot stop a deploy; if the audit cannot run (no lockfile, offline, timeout) it says so and continues. Dev dependencies are excluded because the platform build prunes them.

The same step fails the deploy on dependencies the platform build cannot resolve: paths on your machine (`file:`, `link:`, `portal:`, or a relative, absolute, home or Windows drive path) and git checkouts (`git+`, `git://`, `git@`, `github:`, `gitlab:`, `bitbucket:`). Neither is uploaded with the function, so the build would fail later with a less obvious error. Unlike the audit above, this check includes `devDependencies`, because the build installs them before pruning. This is a hard error, not a warning, so `--force` does not bypass it. Publish the packages, or vendor them into the function directory, before deploying.

Both checks are Node-only; C# functions skip them.

## sinch functions dev

Start a local development server with hot reload. The server restarts automatically when you save changes.

On first run, prompts whether to create a tunnel for receiving webhooks locally. Use `--tunnel` or `--no-tunnel` to override.

**Syntax**

```sh
sinch functions dev [options]
```

**Options**

| Option | Description |
|  --- | --- |
| `-p, --port <port>` | Port to listen on (default: `3000`) |
| `-d, --debug` | Enable debugger — creates `.vscode/launch.json` if absent |
| `--tunnel` | Force tunnel creation |
| `--no-tunnel` | Disable tunnel and reset any "always" preference |


## sinch functions status

Show the current status and details of a deployed function.

```sh
sinch functions status [function-id]
```

If `function-id` is omitted, reads it from `sinch.json` in the current directory.

## sinch functions logs

View historical logs for a deployed function. Opens an interactive terminal UI showing a table of requests. Press Enter on any row to see request/response details.

**Syntax**

```sh
sinch functions logs [function-id] [options]
```

**Options**

| Option | Description |
|  --- | --- |
| `-f, --follow` | Stream logs in real-time |
| `-n, --lines <number>` | Number of historical entries to load (default: `50`) |
| `--level <level>` | Filter by log level: `debug`, `info`, `warning`, `error` |
| `--search <text>` | Filter entries containing this text |
| `--since <duration>` | Show logs from the last duration (e.g., `1h`, `30m`, `5s`) |


**Interactive UI controls**

| Key | Action |
|  --- | --- |
| `Up` / `Down` | Navigate rows |
| `Enter` / click | Open request detail |
| `Esc` / `Q` | Close detail or quit |
| `J` | Copy request as JSON to clipboard |
| `C` | Copy request as cURL command to clipboard |


## sinch functions logs stream

Alias for `sinch functions logs --follow`. Connects to the live log stream and displays new requests as they arrive.

```sh
sinch functions logs stream [function-id] [options]
```

## sinch functions download

Download the deployed source code of a function as a ZIP file.

```sh
sinch functions download [function-id]
```

If the function has secrets, `download` offers to fetch and install them locally. With `--non-interactive`, or when there is no TTY to answer on, the fetch is skipped and the command prints the `sinch secrets add` line to run by hand.

## sinch functions delete

Delete a deployed function. Prompts for confirmation unless `--force` is passed.

```sh
sinch functions delete <function-id>
```

## sinch functions docs

Generate AI-powered documentation for the function in the current directory. Reads the function source and writes a `README.md`.

```sh
sinch functions docs
```