Reference · built on requestConnectorVoice & contact center

Sinch

Voice callbacks, omnichannel conversations, SMS delivery, and numbers from Sinch, with callout and messaging actions.

Request accessPricing ↗

About

Sinch is a CPaaS vendor with separate APIs for voice, messaging, and numbers. The Voice API places and controls calls from regional endpoints and reports back through ICE, ACE, DiCE, PIE, and Notify callbacks. The Conversation API sends and receives on SMS, RCS, MMS, WhatsApp, Viber Business, Facebook Messenger, Instagram, Telegram, KakaoTalk, LINE, and WeChat from apps hosted in the US, EU, or BR region. The SMS API handles batches and delivery reports; the Numbers API rents and configures numbers.

Through Fibric, an operator reads a callback or a delivery receipt and proposes a reply on the customer's channel, an SMS batch, or a text-to-speech callout. You approve each one. It runs once and leaves a receipt: channel, recipient, and delivery status.

This is a reference listing. It documents what Fibric would read from Sinch and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Voice call events posted to your callback URL: ICE on an incoming call, ACE when answered, DiCE on disconnect, PIE after prompt input, and Notify
  • Call and conference state through GET /calling/v1/calls/id/{callId} and /calling/v1/conferences/id/{conferenceId}
  • Inbound messages, delivery receipts, and conversation lifecycle through Conversation API webhooks such as MESSAGE_INBOUND, MESSAGE_DELIVERY, CONVERSATION_START, and OPT_OUT
  • Message history through GET /v1/projects/{project_id}/messages and the conversations and contacts endpoints
  • SMS batch status, delivery reports, and inbound messages through the SMS API under /xms/v1/{service_plan_id}
  • Active numbers and their SMS service plan configuration through the Numbers API

Proposed actions

  • Target capability: propose a text-to-speech or conference callout through POST /calling/v1/callouts
  • Target capability: propose a change to a live call or leg through PATCH /calling/v1/calls/id/{callId}, or a participant mute or removal in a conference
  • Target capability: propose a message on the contact's channel through POST /v1/projects/{project_id}/messages:send
  • Target capability: propose an SMS batch through POST /xms/v1/{service_plan_id}/batches, with a callback_url for its delivery report

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Text a shift notice and read the reply

    The operator proposes an SMS batch to the affected staff with a callback_url for the delivery report, then reads inbound replies from the inbounds endpoint to mark who confirmed.

    With Schedule Notice

  • Send an ETA on the customer's channel

    Using the contact's channel in the Conversation API, the operator proposes one messages:send with the arrival window. MESSAGE_DELIVERY confirms receipt; OPT_OUT stops further notices.

    With ETA Notice

  • Call a detractor back with a spoken message

    After a low survey score the operator proposes a ttsCallout from your Sinch number offering a callback slot. ACE and DiCE show whether the call was answered and how long it lasted.

    With Detractor Callback

  • Hand a conversation from bot to agent

    When MESSAGE_INBOUND shows a question the automation cannot answer, the operator proposes assigning the conversation to a person and posts the transcript so far into the agent's queue.

    With Bot Handoff

Requirements

  • A Sinch account with a project, a Voice application key and secret, and access keys from the Sinch Build Dashboard
  • A Conversation API app in the US, EU, or BR region with channel credentials, addressed at that region's server
  • Numbers rented through the dashboard or the Numbers API and assigned to the app or SMS service plan; US numbers need a 10DLC campaign ID
  • An HTTPS callback endpoint that returns a 200 to 299 status and checks the Sinch signature headers
Authentication
Voice uses the application key and secret as Basic auth or a signed request (application key:signature, HMAC-SHA256 with x-timestamp); Conversation and Numbers use a project Key ID and Key Secret exchanged at https://auth.sinch.com/oauth2/token for a one-hour Bearer token; SMS uses the service plan's API token.

Limits

  • Conversation API projects are limited to 800 requests per second; an app's MT queue holds 500000 messages and drains at 20 per second by default
  • Basic authentication is for testing only and heavily rate limited; production traffic must use OAuth access tokens
  • Voice conference rooms have regional scope; participants from different regions must be forced onto one regional endpoint
  • A Conversation API app can register at most 5 webhooks; callbacks are not retried on 4xx responses other than 429

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Sinch ↗

Questions and answers

How does Sinch prove a callback came from Sinch?
Voice callbacks are signed with your application key and secret: the authorization header carries application key:signature, an HMAC-SHA256 over the verb, Content-MD5, content type, x-timestamp, and path. Conversation API webhooks with a secret send x-sinch-webhook-signature-timestamp, nonce, algorithm HmacSHA256, and x-sinch-webhook-signature over rawBody.nonce.timestamp.
Which region does a Conversation API call go to?
The one where you created the app. Servers are us.conversation.api.sinch.com, eu.conversation.api.sinch.com, and br.conversation.api.sinch.com; the wrong region returns 404. Voice has its own hosts, calling-use1, calling-euc1, calling-sae1, calling-apse1, and calling-apse2, with calling.api.sinch.com redirecting to the nearest.
When does Sinch retry a webhook?
Conversation API callbacks are retried after a 5xx, a 429, a network timeout, or a failed OAuth2 token fetch. They are not retried after other 4xx responses, nor to test domains such as webhook.site or ngrok.io. Any status from 200 to 299 counts as delivered.
Ask about Sinch

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Sinch through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy