Configuration

How the Sinch CLI stores its settings, switches between projects, and exposes global flags and debug output. For the sinch config command itself, see the config command reference.

Config file

Configuration is stored in ~/.sinch/config.json. Use sinch config set or sinch auth login to update values.

Field	Description
`projectId`	Your Sinch project ID
`apiUrl`	SinchFunctions API URL (defaults to production)
`keyId`	Public key identifier (non-secret)
`defaultVoiceServiceId`	Voice v2 service `init` last picked, preselected on the next `init` (override with `--voice-service-id`)
`autoUpdate`	Install CLI updates automatically (default off)

Key secrets are never written here — they live in your OS keychain. Only non-secret identifiers are stored in config.json.

Environment variable override

For CI/CD pipelines, bypass the keychain with environment variables:

SINCH_PROJECT_ID=...
SINCH_KEY_ID=...
SINCH_KEY_SECRET=...

When all three are set, the CLI uses them instead of the stored profile's credentials and project — no sinch auth login required. Set them together: with only SINCH_KEY_ID and SINCH_KEY_SECRET, the project still comes from the active profile.

See CI/CD for complete GitHub Actions and GitLab CI examples.

Config profiles

Profiles let you switch between multiple Sinch projects without re-authenticating.

sinch config profile create staging    # create a new profile
sinch config profile use staging       # switch to it
sinch config profile list              # show all profiles
sinch config profile delete staging    # remove a profile

To run commands against another project, switch the active profile with sinch config profile use <name>. The --profile <name> flag is honored only by sinch auth login and sinch config get|set|list. Every other command uses the active profile and ignores the flag without a warning. auth login --profile <name> and config set --profile <name> also make that profile the active one, so later commands use it too. A misspelled name creates a new profile instead of failing.

Global flags

Flag	Description
`-h, --help`	Show help for the current command
`-V, --version`	Print CLI version
`--profile <name>`	Use a specific credential profile. Only `auth login`, `config get`, `config set` and `config list` honor it. `auth login` and `config set` also make it the active profile

Update environment variables

Variable	Effect
`SINCH_NO_AUTO_UPDATE=1`	Never install updates automatically
`SINCH_AUTO_UPDATE=false`	Same. Also accepts `0`, `no`, `off`
`SINCH_AUTO_UPDATE=true`	Opt in, unless `autoUpdate` is explicitly `false` in the config

The environment can always turn auto-update off, but can only turn it on when you have not explicitly turned it off with sinch config set autoUpdate false. That way a project you cloned cannot re-enable unattended installs on a machine whose owner declined them.

Values that are not recognised as true or false are ignored rather than treated as "on", so a stray export SINCH_AUTO_UPDATE= does not silently opt you in.

See Updating for what auto-update does.

Debug environment variables

Variable	Effect
`SINCH_DEBUG=1`	CLI debug logs (operations, timing)
`SINCH_DEBUG=2`	+ HTTP requests (method, URL, status)
`SINCH_DEBUG=3`	+ request headers (redacted)

Also configurable via sinch config set debug <0-3>. Levels 2–3 cover both the axios-based commands (functions, templates, storage) and the SDK-based commands (fax, voice, conversation, numbers). At level 3 the SDK-based commands also log a redacted preview of the request body. Response bodies are not logged, except the body of a failed OAuth exchange, which is logged in full.