Ellipse Gradient for Header

Sinch Integration Guide

Integrate Sinch SMS, voice, verification, phone-number, and conversational messaging capabilities with enterprise systems through product-specific REST APIs and callbacks.

Sinch integration options at a glance

Sinch provides product-specific REST APIs for SMS, Voice, Verification, Conversation, phone numbers, and related services. Selected products support webhook-style callbacks for delivery reports, inbound messages, verification outcomes, voice events, and conversation events. The SMS API also supports batch message submission and subsequent status tracking. Authentication varies by product and can include API credentials, HTTP Basic Authentication, or bearer tokens. Martini can consume these APIs from workflows, expose REST endpoints for Sinch callbacks, map product payloads into enterprise models, schedule reconciliation, and apply validation, correlation, retry, and consent rules.

Integration pointSupported by Sinch?Common use casesHow Martini supports it
REST APIsYesSinch provides product-specific REST APIs for SMS batches, phone numbers, verification requests, voice calls, conversation messages, and status retrieval.Martini workflows can consume Sinch REST endpoints, transform requests and responses, and expose controlled APIs around Sinch operations.
Webhooks and outbound callbacksLimitedSelected products provide callbacks for SMS delivery reports, inbound SMS, verification outcomes, voice events, and conversation events.Martini can expose REST endpoints, validate product-specific callback authentication, normalize payloads, and route events to enterprise systems.
Bulk and asynchronous APIsYesThe Sinch SMS API supports batch message submission for multiple recipients and returns identifiers for later status or delivery tracking.Martini can validate and chunk recipients, submit batches, persist batch identifiers, and reconcile asynchronous results.
AuthenticationYesDepending on the product, Sinch uses project or application credentials, API tokens or secrets, HTTP Basic Authentication, or bearer tokens.Martini can keep environment-specific credentials in secrets and apply the required authentication configuration to API consumption or callback endpoints.
File and media handlingLimitedConversation messages may reference externally hosted media or rich content, but a general Sinch file or attachment API was not confirmed.Martini can retrieve, transform, or relay media references when required by a workflow without treating Sinch as general file storage.
Scheduled synchronizationYesPolling can reconcile message, batch, verification, call, or conversation status when callbacks are unavailable or insufficient.Martini scheduler-triggered workflows can retrieve pages of status data, compare checkpoints, and update downstream systems.
GraphQL APIsNot confirmedNo official Sinch GraphQL API was confirmed in the reviewed documentation; product REST APIs are the recommended approach.Martini supports GraphQL generally, but a Sinch integration should not depend on GraphQL without product-specific confirmation.
SOAP APIsNot confirmedNo official Sinch SOAP API was confirmed in the reviewed documentation.Martini supports SOAP generally, but Sinch integrations should use documented REST APIs unless a specific product confirms SOAP.

How Sinch exposes data and business events

Sinch REST APIs

REST is Sinch's primary integration mechanism, with separate product APIs for SMS, Voice, Verification, Conversation, phone numbers, and status operations.

Martini implementation pattern

Martini implementation pattern: a workflow authenticates to the applicable Sinch product API, builds a product-specific request, validates the response, stores identifiers such as batch or verification IDs, and maps the result into the target application model.

Implementation sequence

Receive an application event or scheduled trigger
Load the product-specific Sinch credentials
Validate consent, phone numbers, and required fields
Call the relevant Sinch REST API
Store the returned identifier and correlation data
Map the response to the target system

Sinch callbacks

Sinch supports webhook-style callbacks for selected events, including SMS delivery reports, inbound SMS, verification outcomes, voice events, and conversation updates. Coverage varies by product and event.

Martini implementation pattern

Martini implementation pattern: expose a REST endpoint for the selected callback, validate the product-specific authentication or signature, reject duplicates using stable identifiers, normalize the event, and route it to the appropriate enterprise workflow.

Implementation sequence

Receive the Sinch callback
Validate the documented callback authentication
Parse and validate the event payload
Check the event or message correlation key
Map the event to the target application
Return the appropriate callback response

SMS batch APIs

The Sinch SMS API supports batch-oriented message submission for multiple recipients and later tracking through batch and delivery information.

Martini implementation pattern

Martini implementation pattern: a workflow validates recipient limits and message content, chunks large submissions when required, submits batches, persists returned identifiers, and schedules reconciliation for delivery states not received through callbacks.

Implementation sequence

Collect and validate recipient messages
Normalize phone numbers and apply consent rules
Split requests according to product limits
Submit the SMS batch
Store the batch identifier
Reconcile delivery and failure states

Scheduled status reconciliation

Polling is useful when callbacks are unavailable, incomplete, or operationally supplemented by periodic status checks for messages, batches, verifications, calls, or conversations.

Martini implementation pattern

Martini implementation pattern: a scheduler starts a workflow from a stored checkpoint, retrieves paginated status data, compares it with business transactions, applies idempotent updates, and records the next checkpoint.

Implementation sequence

Start the scheduled reconciliation workflow
Load the last checkpoint
Retrieve the next page of Sinch status data
Correlate results with business transactions
Apply idempotent updates
Persist the checkpoint and processing outcome

Common Sinch integration patterns

Pattern 1: Orchestrate customer notifications

When to use this pattern

Use this pattern when a CRM, service platform, commerce application, or ERP event should trigger a Sinch SMS notification and the organization must retain delivery status.

Integration direction
Salesforce
Martini
Sinch
Example Mapping
Sinch FieldCanonical FieldTarget Field
recipientcustomer.phoneNumberto
message bodynotification.textbody
external transaction IDcommunication.correlationIdclient_reference
Martini implementation pattern

Martini receives or retrieves the source event, validates consent and E.164 formatting, applies country and message rules, calls the Sinch SMS API, stores the batch or message identifier, and processes a later callback or polling result. Transient failures are retried without resubmitting an already accepted batch.

Martini capabilities used
  • workflows
  • API consumption
  • data mapping
  • business rules
  • secrets management
  • error handling

Pattern 2: Route inbound SMS to support

When to use this pattern

Use this pattern when inbound SMS messages should be associated with a customer, case, or conversation in a support platform.

Integration direction
Sinch
Martini
Zendesk
Example Mapping
Sinch FieldCanonical FieldTarget Field
sender phone numbercontact.phoneNumberrequester.phone
message textconversation.messagecomment.body
Sinch event identifierevent.idexternal_event_id
Martini implementation pattern

Martini exposes a callback API, validates the Sinch request, normalizes the sender number, resolves the customer or ticket, and writes the inbound message to the support platform. Idempotency checks prevent duplicate tickets or comments when callbacks are retried.

Martini capabilities used
  • API exposure
  • webhook consumption
  • data mapping
  • validation
  • business rules
  • error handling

Pattern 3: Synchronize verification outcomes

When to use this pattern

Use this pattern for onboarding, authentication, or account-change processes that initiate Sinch Verification and must update a downstream user or account record.

Integration direction
Workday
Martini
Sinch
Example Mapping
Sinch FieldCanonical FieldTarget Field
phone numberuser.phoneNumberidentity
verification request identifierverification.requestIdexternal_verification_id
verification statusverification.resultphone_verification_status
Martini implementation pattern

Martini initiates the Sinch Verification request, persists the request identifier and originating transaction, then receives the result through a supported callback or scheduled status request. Business rules determine whether onboarding proceeds, retries, or enters manual review.

Martini capabilities used
  • workflows
  • API consumption
  • API exposure
  • data mapping
  • business rules
  • scheduled execution

Pattern 4: Reconcile SMS delivery reports

When to use this pattern

Use this pattern when delivery callbacks are incomplete or when operational reporting requires periodic comparison of Sinch status with enterprise messaging records.

Integration direction
Sinch
Martini
ServiceNow
Example Mapping
Sinch FieldCanonical FieldTarget Field
batch identifiercommunication.batchIdu_sinch_batch_id
delivery statuscommunication.deliveryStatusu_delivery_status
failure reasoncommunication.failureReasonu_failure_reason
Martini implementation pattern

A scheduled Martini workflow retrieves paginated Sinch status information from the relevant product API, correlates it with stored transactions, distinguishes acceptance from delivery, updates ServiceNow, and applies controlled retry or escalation rules for failures.

Martini capabilities used
  • scheduler triggers
  • API consumption
  • pagination handling
  • data mapping
  • idempotency
  • monitoring

Applications commonly integrated with Sinch

Sinch can be integrated with customer, service, commerce, workforce, and enterprise applications when organizations need messaging, verification, voice, or delivery-status automation. The following are practical architecture patterns rather than claims of packaged Sinch integrations.

Application Scenario Direction Martini Pattern
Salesforce Send customer notifications, verification messages, and appointment reminders, then associate delivery outcomes with Contacts, Leads, Cases, or custom objects. Salesforce → Martini → Sinch A Martini workflow receives Salesforce events or scheduled extracts, validates consent and phone numbers, calls the relevant Sinch REST API, stores the batch or message identifier, and processes delivery callbacks back into Salesforce.
ServiceNow Send incident, change, approval, or service notifications and update records when delivery or verification events occur. ServiceNow → Martini → Sinch Martini orchestrates outbound notifications from ServiceNow, applies routing and throttling rules, invokes Sinch, and exposes a callback API to correlate delivery results with incidents or requests.
Zendesk Notify customers about ticket activity and associate inbound SMS replies with support tickets. Zendesk → Martini → Sinch Martini maps ticket and customer data to Sinch SMS requests, normalizes inbound SMS callbacks, resolves the customer or ticket, and writes the message and delivery status to Zendesk.
HubSpot Send transactional or workflow-driven SMS based on Contacts and Deals while retaining delivery status for customer engagement processes. HubSpot → Martini → Sinch A Martini workflow consumes HubSpot events or scheduled data, checks messaging consent, transforms contact fields to the Sinch request model, and synchronizes status using callbacks or polling.
Microsoft Dynamics 365 Send customer service, sales, and field-service notifications and synchronize communication outcomes with Customer, Case, or Activity data. Microsoft Dynamics 365 → Martini → Sinch Martini translates Dynamics events into Sinch SMS or verification requests, persists correlation identifiers, and routes Sinch callbacks into Dynamics activities or cases.
Shopify Send order, shipment, delivery, and customer-service notifications to shoppers. Shopify → Martini → Sinch Martini receives order or fulfillment data, applies country, recipient, and consent rules, submits Sinch messages, and forwards delivery outcomes to the commerce or customer-service process.
Workday Deliver employee onboarding, authentication, or operational notifications to mobile users. Workday → Martini → Sinch A scheduled or event-driven Martini workflow transforms Workday worker or onboarding data, invokes Sinch Verification or messaging APIs, and records the resulting identifiers and status.
SAP S/4HANA Send order, logistics, supplier, or operational notifications to customers, employees, or partners. SAP S/4HANA → Martini → Sinch Martini consumes SAP events or APIs, maps business transactions into Sinch message requests, enforces recipient and throughput rules, and returns delivery status to SAP or an operational store.

How to build a Sinch integration in Martini

Objective

Configure the Sinch product, project or application identifiers, and environment-specific credentials required by the selected API.

Instructions in Martini

  • Identify the Sinch product and API version in use
  • Store API keys, secrets, Basic Authentication values, or bearer-token configuration as environment-specific secrets
  • Configure the required REST API authentication
  • Restrict credentials to the operations required by the workflow

Objective

Select an event-driven, API-led, or scheduled entry point based on the Sinch capability and the business process.

Instructions in Martini

  • Use a Martini API for Sinch callbacks or inbound SMS
  • Use an application event or API request for outbound messaging
  • Use a scheduler when status reconciliation is required
  • Confirm the selected Sinch product supports the required callback event

Objective

Obtain Sinch requests, callbacks, or status data and preserve the identifiers needed for correlation.

Instructions in Martini

  • Validate callback authenticity where applicable
  • Retrieve status pages using the documented pagination model
  • Persist project, application, batch, message, call, verification, or conversation identifiers
  • Distinguish API acceptance from later delivery or completion

Objective

Coordinate Sinch calls, downstream updates, checkpoints, and alternate paths in a maintainable Martini workflow.

Instructions in Martini

  • Call the relevant Sinch REST API
  • Route SMS, Voice, Verification, or Conversation processing by product and event
  • Add asynchronous reconciliation where callbacks are insufficient
  • Keep product-specific behavior isolated in reusable workflow components

Objective

Convert Sinch product payloads into canonical business and target-application models.

Instructions in Martini

  • Normalize phone numbers to the required international format
  • Map message, recipient, status, and correlation fields
  • Transform callback payloads into CRM, support, identity, or operational models
  • Preserve raw identifiers and relevant failure information

Objective

Enforce consent, recipient, throughput, duplicate, and business-status rules before changing systems or sending messages.

Instructions in Martini

  • Check opt-in, opt-out, sender, country, and content policies
  • Chunk SMS batches according to product limits
  • Reject duplicate callbacks and already-processed transactions
  • Use controlled retries for transient failures without duplicating accepted messages

Common Sinch data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
ProjectsTop-level organizational and configuration containers for Sinch applications, credentials, and products.Configuration stores, identity platforms, audit systemsMartini treats project identifiers and configuration as environment-specific values and keeps secrets outside workflow logic.
ApplicationsProduct-specific configurations used for SMS, verification, conversations, or other Sinch services.Configuration management, CRM, onboarding platformsMartini references the relevant application identifier in API requests and maps application context into correlation and audit data.
SMS batchesGroups of SMS messages submitted to multiple recipients, with identifiers used for status and delivery tracking.Salesforce, ServiceNow, Zendesk, SAP S/4HANA, data storesMartini validates recipients, chunks requests where necessary, stores batch identifiers, and reconciles delivery states.
Phone numbersSinch-provisioned or managed numbers used for sending, receiving, voice calls, or verification.CRM, contact centers, service platforms, configuration storesMartini normalizes numbers, maps sender and destination roles, and applies country and product validation rules.
Verification requestsRequests and attempts used to verify a phone number or identity through SMS, flash call, or voice methods.Identity systems, onboarding platforms, Workday, SalesforceMartini initiates requests, persists verification identifiers, receives or polls results, and updates the originating process.
ConversationsConversation API interactions containing messages, participants, channels, and delivery or event information.CRM, support platforms, customer data storesMartini normalizes participants, messages, channel events, and delivery information for downstream systems.

Authentication and security considerations

Product-specific authentication

Sinch authentication varies by product and API generation. Integrations may use project or application identifiers with API tokens or secrets, HTTP Basic Authentication, or bearer tokens.

Credential protection

Martini can store Sinch credentials as environment-specific secrets and apply only the permissions required by each workflow.

Callback validation

Sinch callback authentication or signing is product-dependent. Validate requests using the mechanism documented for the relevant Sinch product rather than relying only on a URL or sender address.

Messaging compliance

Apply consent, opt-out, sender registration, country, and content rules before invoking Sinch messaging or voice operations.

Operational considerations for Sinch integrations

Throughput and limits

Plan for Sinch API rate limits, SMS throughput, carrier restrictions, account quotas, recipient limits, and message-size constraints. Chunk large SMS submissions where required.

Pagination and reconciliation

Follow the relevant Sinch cursor or page-token model when retrieving numbers, messages, delivery reports, verification data, or conversation information. Use scheduled workflows for reconciliation when callbacks are unavailable or incomplete.

Idempotency and correlation

Callbacks can be retried or duplicated. Persist batch, message, call, verification, conversation, or event identifiers and use them to prevent repeated downstream updates or duplicate messages.

Product-specific schemas

SMS, Voice, Verification, Conversation, and number APIs can differ in authentication, identifiers, status values, pagination, and callback formats. Isolate mappings by product and test representative payloads.

Observability

Record Sinch identifiers and originating business references, distinguish API acceptance from delivery, and use Martini workflow error handling and logs to investigate failures.

Why use Martini instead of scripts or point-to-point integrations?

Orchestrate more than one API call

Martini coordinates Sinch REST calls, callbacks, scheduled reconciliation, downstream updates, validation, and business rules in a maintainable workflow rather than scattering logic across scripts.

Separate product-specific mappings

Sinch exposes distinct product APIs and payloads. Martini keeps those mappings and transformations explicit while allowing shared correlation, compliance, and error-handling logic to be reused.

Support multiple integration styles

Martini can consume Sinch APIs, expose controlled REST endpoints for callbacks, and run scheduled workflows when asynchronous status must be reconciled.

Improve operational reliability

Centralized secrets, validation, idempotency, retry handling, logging, and deployment configuration make Sinch integrations easier to operate than isolated point-to-point scripts.

Frequently asked questions

How can Sinch be integrated with enterprise systems?

Sinch can be integrated through its product-specific REST APIs for SMS, Voice, Verification, Conversation, phone numbers, and status operations. Selected products also provide callbacks for delivery reports, inbound messages, verification outcomes, voice events, and conversation events. Scheduled polling can supplement callbacks.

Can Martini integrate with Sinch?

Yes. Martini can consume Sinch REST APIs from workflows, expose REST endpoints for supported Sinch callbacks, map product-specific payloads, schedule status reconciliation, and apply validation, correlation, retry, and business rules.

Do I need a connector to integrate Sinch with Martini?

No. A dedicated Sinch connector is not required. Martini can use Sinch's documented REST APIs, product-specific authentication methods, and supported callbacks through workflows and APIs.

Is there any extra Lonti cost to integrate Sinch with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate Sinch. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Sinch, carriers, cloud infrastructure, or other third parties based on subscription, usage, and deployment model.

Which Sinch integration methods should new projects use?

REST APIs are Sinch's primary integration method. Use the product-specific SMS, Voice, Verification, or Conversation API and add callbacks where the required event is supported. No official Sinch GraphQL or SOAP API was confirmed.

Does Sinch provide webhooks or callbacks for events?

Sinch supports webhook-style callbacks for selected product events, including SMS delivery reports, inbound SMS, verification outcomes, voice events, and conversation events. Coverage is product- and event-specific rather than universal.

How should Sinch data synchronization work?

Use callbacks for supported near-real-time events and scheduled API polling for reconciliation or event types without sufficient callback coverage. Store stable Sinch identifiers, follow pagination, distinguish submission from delivery, and apply idempotent updates.

How does Martini handle Sinch errors, retries, and duplicate events?

Martini can validate payloads, classify transient and permanent failures, retry controlled operations, persist correlation identifiers, and reject duplicate callbacks. SMS workflows should avoid resubmitting an accepted batch merely because a later delivery report is delayed.

Related Martini documentation

APIs

Workflows

Data

Security

Operations

Integrate Sinch with Martini

Use Martini to orchestrate Sinch messaging, verification, voice, and conversation workflows with the enterprise systems that depend on them.

EXPLORE MARTINI
BOOK A DEMO