How Wani's telephony credentials are configured today
This guide explains how Wani's telephony provider is currently configured using deployment-wide credentials, as there is no self-serve, per-workspace connect flow available yet. It details the manual setup process for the Auth ID and Token, the shared caller-ID mechanism, and the security verification for inbound webhooks.
1 What exists today
Wani's telephony provider is currently wired at the deployment level via two credentials, not through a per-workspace connect wizard. This is unlike Wani's voice-engine bring-your-own-key system, which does have a per-workspace credential model; telephony does not, today. This setup means all workspaces under a single deployment use the same underlying telephony account and identity until per-workspace provisioning is available.
2 Get an Auth ID and Auth Token
Create an account at the provider's developer console to begin. Once logged in, locate and copy the Auth ID and Auth Token displayed in your account settings. These two values are named VOBIZ_AUTH_ID and VOBIZ_AUTH_TOKEN in this deployment's environment file, and they are the only secrets required to authorize the deployment to make calls on your behalf.
3 Set the deployment-wide credentials
These two values are set once for the entire deployment, not individually for each workspace, as VOBIZ_AUTH_ID and VOBIZ_AUTH_TOKEN. Ensure they are correctly placed in your deployment's environment configuration so the telephony service can initialize.
4 The shared caller-ID number
An optional fallback caller-ID number, WANI_VOBIZ_NUMBER_E164, can be configured for outbound calls placed before a specific workspace has its own dedicated number. This allows the shared deployment to maintain a consistent identity for outbound calls until a workspace has provisioned its own number.
5 Confirm the credential is recognized
A read-only status endpoint, GET /telephony/providers, reports whether Vobiz's credentials are present and valid without ever echoing their actual values -- it names the required env vars and whether each is missing. You can query this endpoint to verify that the deployment has successfully loaded the credentials. This helps troubleshoot connection issues by confirming that the system recognizes the provider as configured.
6 Inbound webhooks are signature-verified
Inbound call events from this provider are verified with HMAC signatures before any data is trusted. An unsigned or mis-signed request is rejected immediately, preventing spoofed events from entering your system. This security measure ensures that only legitimate notifications from the provider's infrastructure are processed by the telephony service.
7 What isn't built yet
There is no in-product wizard available today for a workspace to paste in its own credentials for this provider and get its own number. Until one exists, a workspace's own account must be configured by hand at the deployment level by an administrator.
Next
Status: reviewed · reviewed by claude-sonnet-5