Omni-Channel Messaging
Documentation /

Omni-Channel Messaging Guide

 

This user guide describes how the Syniverse Communication API services are used. The Syniverse Communication API service offers a set of high functioning REST-based APIs with support for Omni-channel Messaging capabilities suitable to Businesses, Individual Developers and Enterprise Customers. Our simple and easy to use set of APIs allows developers to add communication functionalities that support a wide range of use cases to their application in no time.

Prerequisites

To use the Communication API services, the following items need configured:

  • Company Account in Syniverse Developer Community
  • Subscription to the Voice & Messaging Offering
  • A Syniverse Application
  • Account with funds in Syniverse Developer Community
  • optional Whitelisted number for test message sending

The Syniverse API powers the Synverse Omni-Channel Messaging CPaaS (Communication Platform as a service) platform and comprises of the following:

*These services have additional charges associated with them

Quick Start and User Guide

The API service supports personalizing messages, sending and receiving messages over multiple channels recognizing and tracking threads of conversation, and conversion events, and providing a higher level of analytical information regarding communication events.; The Syniverse Communication APIs are granular but suitable for reuse within solutions that perform higher level functionality.

Customers that subscribe to the Syniverse Communication API service offering should refer to API specification document for details on available resources, API call configurations and specifications of attributes that are required to successfully integrate Voice & Messaging into their applications . Please refer to individual channel services for specifics on how to use them. SCG Quick Start Guide.

Key Platform Concepts

The following concepts are used in this document:

Customer – This entity or Developer represents the organization making use of the APIs offered by our platform. The Customer might be a Corporation, individual Developer, or an Enterprise Developer or an entity (Reseller) that the service has been resold to. Each Customer has:

  • A specific credential (user/password,Auth Key) which is used to authenticate itself when connecting to the Syniverse services.
  • One or more applications which make use of the service.
  • Service offering : Voice & Messaging API Service

End User – The end user is a non-Customer message recipient or sender. A Customer can send messages or voice call to End Users and End Users can send messages or incoming call to a Customer.

Application – An application refers to a particular program, set of programs, or use case which makes use of the REST APIs to performing messaging tasks or which is called when messages are sent by mobile subscribers / contacts to a given Sender address (E.g. SMS short code, Longcodes, Device token email address, etc.). All applications have:

  • Application ID
  • Auth Key – used to identify the application in API calls.
  • One or more Sender IDs which are used for communication.

Sender ID - An address that the Customer application can send messages or voice calls from. Before sending a message or a Voice call, a Customer must provision at least one Sender ID from which the message or voice call will be sent. The Syniverse Communication API service provides APIs to request the provisioning of a new Sender ID and checking on the status of a provisioning request. The Syniverse Communication API service supports "Bring your own" Sender Address as well as the ability to purchase a Sender Address address that is owned by Syniverse.

Channel - A channel of communication represents a collection of one or more Sender Addresses. For example, a specific set of SMS short codes that can be used to send text based messages. When sending messages using a Channel, Syniverse Messaging API service will choose the most appropriate Sender Address to use for delivering a given message to a given recipient address.

Contacts – contacts represent a person who can send/receive messages as a way to interact with applications. i.e. they represent mobile subscribers/message recipients with whom the application wishes to interact, but are not constrained to being people. They can actually represent any addressable destination that can be reached by the communication media, including external applications. Contacts are identified by an ID of significance to the application, and additional attributes (which can be referenced in messaging.) For each channel that the recipient chooses to participate in:

  • One or more recipient addresses. (Mobile number, Push device token, WeChat/Facebook ID, etc.)
  • Other attributes configured by service-provider specific metadata, which can be used in message personalization.

Contact Groups – Contact Groups support bulk forms of interaction. A contact group is a group of contacts, and can be the target of messaging API calls. Groups can also be used to represent the group of people who have granted or withdrawn consent to participate in messaging engagements with a specific application. Contact Groups can also be created dynamically via API based on criteria expressed in terms of Contacts and their associated group memberships and messaging history. This supports application which may be using contact groups as a way to perform Customer segmentation of follow-up to previous bulk campaigns.

Message Request – a record of an incoming request which indicates the Customer would like to send a message to one or more recipients. The Message Request contains the list of recipients and the body of the message. The body of the message may contain the whole message text, contain an inline template, or contain parameters that are used to generate a message based on a corresponding sender address template.

Message – a record of a message that is being delivered to a recipient end user or a message that was received from an end user. There is one message for each recipient in a Message Request. This resource makes it possible to see who messages have been sent to (if the target was expressed as dynamic criteria), and track the delivery status for each recipient. This resource is also used to read the content of messages sent from the end user to the Customer.

Events – represents individual events which occur that potentially provide feedback messages which the Syniverse Communication API service can send to a Customer. These are message-specific, and represent: delivery receipts, delivery failure, delivery timeout, conversion (accessing an active element in the rendered message), replies from the recipient (that can be correlated to a prior outbound message), and recipient-initiated messages sent to the application, etc.

Conversion – A conversion is a record of a response from a user to a message, not represented by a direct reply, but rather by recipient interaction (behavior.) For example, following a URL provided in an SMS message is a conversion event. Replying to a message can also be a conversion event. Each conversion event is associated with a recipient disposition (e.g. whether the response was positive or negative.) Conversion events can also be posted by the enterprise/application if these events originate outside of the Syniverse Communication API service’s awareness. (In that context, we provide an optional service that customer can subscribe to which can still track this and provide reporting and analytics based on them.)

Message Template - This is pre-configured message with special key words that can be replaced by Syniverse Communication API service during message processing. There are two types of templates: Dynamic and Static. Static Templates are created and stored in Syniverse Communication API service and associated with one or more Sender Addresses. Dynamic Templates are passed in a Message Request by the Customer. The values used to fill in a template may come from the Contacts service or the message itself.

 

Omni-Channel API Resource Descriptions

Sender Address

A Sender Address is a specific address (SMS short code, long code, email address, FaceBook account ID, etc.) on which an Application can send/receive messages. The Sender Address must be provisioned with the SMS API service system before it can be used. The provisioning process is started by creating a new sender address resource.

In order to send Messages, a Customer must first provision at least one Sender Address or use a Syniverse provisioned Public Channel.

A Customer can have multiple sender addresses of the same type. E.g. multiple shortcodes or combination of long codes, shortcodes or alphanumeric sender addresses.

When a new Sender Address is created, the state is set to Pending Implementation. This starts the provisioning process. Once provisioning process is complete the Sender Address can be used to send and receive messages.

Customers can provision a Sender Address for the following Services:

  • SMS/MMS
  • Push Mobile Notifications
  • Voice API Services
  • Social Messaging (WhatsApp)

All sender addresses have a state, indicating the Sender Addresses availability for messaging. The states reflect the possibility that some Sender Address types may require manual provisioning steps following their initial creation before the channel is usable. When creating a new Sender Address resource the system will automatically assign a "Pending Implementation" state. The allowed state values are:

State Description
Pending Implementation Not yet implemented or usable. This is the initial state that a Sender Address is in if there are manual provisioning steps associated with the Sender Address type.
Implemented Ready to be used (implementation complete.) The Sender Address can transition from this state to Active with a PUT call, indicating the Customers intent to use the Sender Address. Attempts to use the Sender Address will not succeed while in this state. This is the initial state that a Sender Address is in if there are no manual provisioning steps associated with the Sender Address type.
Active Active, and in use. The Sender Address can be used for sending and receiving messages. Registered callbacks may be invoked as events occur on the Sender Address.
Inactive A state that the user can transition the Sender Address to indicate that it should not be used. While in this state, attempts to use the Sender Address will not succeed. The Customer can transition back to active when desired.
Broken Indicates that the Sender Address is currently experiencing technical difficulties and is not functioning. Attempts to send messages will fail, and no callbacks will be issued in regard to events.
Delete Pending Indicates that the Sender Address is being permanently deactivated. The provisioned resources associated with the Sender Address will be released, and the channel will be transitioned to the deleted state when that is done.
Deleted Indicates that the Sender Address is inactive and no longer usable. All implemented resources (e.g., short codes) have been released or de-provisioned. This is the end of the lifecycle of the channel. The Sender Address cannot be "un deleted." A new channel address must be created if the same address is to be reused

In Summary, Customer can only change the status (via the PUT operation) as follows:

  • An implemented Sender Address to active.
  • Active to inactive.
  • Inactive back to active.
  • Inactive to deactivation pending (to request deactivation or de-provisioning of the Sender Address).

Sender Address Types

A Sender Address has a type which defines how messages are processed and routed and which type of content can be sent/received using the Sender Address.

The Messaging API service provides a Sender ID Type resource which can be retrieved to discover the attribute of the various types that are supported.

The Sender Address Type resource defines the various types that can be used. The currently supported types are:

  • Longcode (Voice/Messaging)
  • Toll-free
  • Push
  • Shortcode
  • Alphanumeric
  • Whatsapp

For more information, call the Sender ID API resources to list the Sender ID type resources.

Sender Addresses Ownership

A Sender Address has an associated "Ownership" values. Ownership determines who can use a particular Sender Address.

There are two possible values:

  • Private
  • Pre-Provisioned

When a Customer provisions a Sender Address, the newly created Sender Address is owned by the Customer and is considered "Private". No other Customers can use that Sender Address. The second type is "Pre-Provisioned". These are Sender Addresses that exist in Syniverse Messaging API service but cannot be used until purchase by a Customer. When a Customer purchases a pre-provisioned Sender Address the ownership is changed to "Private".

Sender Address Templates

Message templates can be created and associated with a Sender Address. For Private Sender Addresses, the use of an associated template is optional.

Sender Address Countries

This is a list of countries that the sender address can be used to send messages to and receive messages from. This is set by Syniverse during provisioning.

Sender Address Formats

There are 3 different Sender address formats supported on platform:

  • Sender_ID : This is a pseudo-random string generated using a sender address (Shortcode, Longcode, Toll-free number, Facebook ID etc) e.g.
curl -X POST https://api.syniverse.com/scg-external-api/api/v1/messaging/messages \
-H "Authorization: Bearer [token]" \
-H "Content-Type: application/json" \
-d '{"from":"sender_id:5c96zku8zUTkxxxxxxxxxx",
"to":"+1346787XXXX",
"body":"Hello from SCG message by sender_id"}'
  • Address : This is the Sender address value for your shortcode, Longcode or Toll-free number. Please note that a Sender ID needs to be created before the Address format can be used.
curl -X POST https://api.syniverse.com/scg-external-api/api/v1/messaging/messages \
-H "Authorization: Bearer [token]" \
-H "Content-Type: application/json" \
-d '{"from":"address:1833667XXXX",
"to":"+1346787XXXX",
"body":"Hello from SCG message by address"}'
  • Sender Address alias : Assigns an alias to a Sender ID.

First assign an alias for SenderId (for example: 55555 shortcode senderId is - Uu4txaiKbAWjMN8427QTM2)

curl -X POST https://api.syniverse.com/scg-external-api/api/v1/messaging/sender_ids/5c96zku8zUTkxxxxxxxxxx \
-H "Authorization: Bearer [token]" \
-H "Content-Type: application/json" \
-d '{"alias":"TFN_XXXX",
"version_number":"14"}'

Once you assign an alias name to your Sender ID, then you can use the name as shown below:

curl -X POST https://api.syniverse.com/scg-external-api/api/v1/messaging/messages \
-H "Authorization: Bearer [token]" \
-H "Content-Type: application/json" \
-d '{"from":"alias:TFN_XXXX",
"to":"+1346787XXXX",
"body":"Hello from SCG message by alias"}'

Channel

Channels represent a set of Sender Addresses.When sending a message using a Channel, the API service chooses one of the Sender Addresses based on the following factors.

  • Destination Address Country
  • Destination Address Type (e.g. Mobile number, Device Token, etc)
  • Current Messaging Throughput for Sender Address

A Channel can be used to allow one message to be delivered to many disparate recipients. For example, a Customer may create a Channel that has multiple Sender Addresses with reach to many different countries. The customer can then use this Channel to send a message to any of these countries.Channels are usually Private (owned and created by the customer) or Public (owned and created by Syniverse). A private channels requires one or more Sender address that have been provisioned and owned by a Customer.

Message Request

Message Requests represent instances of a request to send a message from a Customer to more than one recipient. A message request can contain a list of recipients (addresses, Contact IDs, groups or a query) and message content. Message requests can exist within the context of threads, which are shown via the reply chain associated with the messages. (A given message can be denoted as a reply to another, and this supports cross-channel threading.)

When a Message Request is created, a message is delivered to each recipient in the request and a Message resource is created for each recipient. The Message resources will contain the Message Request Id of the associated Message Request. The Message resources can be used to track the status of each individual message.

If the application wants delivery receipts as the messages are delivered, an appropriate Event Handler can be established on the channel, and associated with the application. This will cause the delivery receipt callbacks to the application-specified URL as the messages sent by that application are delivered.

This Message Request resource has an endpoint of {baseURL}/scg-external-api/api/v1/messaging/message_requests  

Message Request State

State Description
Submitted The message has been submitted to the API Service.
Accepted The Message Request has been validated and is accepted for processing.
Rejected The Message Request has failed being validated and will not be processed.
Preparing The Message Request is being processed. Individual messages are being created and delivered.
Transmitting The message request processing is finished. Individual messages are being delivered.
Completed All messages associated with this message request have been sent.
Paused The Message request processing is paused. No individual messages will be delivered until the Message Request state is set back to "Transmitting." A Message Request can enter the Paused state when it is submitted with the "pause before transmit" flag set to true.
Cancelled The Message request has been canceled. Any unsent messages will not be delivered.
Deleted The Message Request has been deleted. It will no longer appear in the list of Message Requests.

Message Request Recipient List

The API supports sending Messages to a multiple recipients using the following recipient reference:

  • By providing the value of the contact_id in the to_address_list field.
  • By providing the recipient addresses (email, phone numbers in array, etc.) in the to_address_list field.

For creation of multiple messages, three options are available:

  1. The list of recipients can be expressed by using either:
    • Providing a list of Contact IDs separated by semicolon in the to_address_list field.
    • Providing a list of recipient addresses separated by semicolon in the to_address_list field.
  2. The message can be sent to all of the contacts in a contact group by providing a contact_group_id in the contact_group_id field.

The type of recipient that each address refers to is denoted with a prefix added to the address in the address list.

The available prefixes are as follows:

Prefix Description
mdn This is the mobile phone number of the recipient in e.164 format.
contact The ID of the Contact in Syniverse Communication API Service.
group The ID of the Group in Syniverse Communication API Service.
voice Phone number of the recipient in e.164 format
psh Device registration ID combined with the push application ID and the Push type (e.g. Apple or Google)
wa WhatsApp recipient address combined with the WhatsApp Business number

The prefix is prepended to the address with the prefix followed by a ":". For example, to send a message to an SMS recipient with the phone number 1-555-111-2222. The address provided in the to_address_list field would be this:

mdn:+15551112222 (E.164 format) or +15551112222

 

Messages

The Message resource represents instances of a request to send a message to a single recipient. This endpoint is suitable for use cases that requires quick messages to single recipients. Use cases like include time-sensitive messages like authentication codes, fraud alerts or conversational messages are best sent via this message resource.

This resource should not be used to send messages to multiple recipeints.

This Message resource has an endpoint {baseURL}/scg-external-api/api/v1/messaging/messages.  

A Message resource can have the following states:

Message States

State Description
Created The Message has been created in the SMS API service and is pending delivery.
Queued The Message has been created but its on a queue waiting to be sent
Sent The Message has been sent to the recipient.
Delivered A delivery report has been received for this Message.
Read A read report has been received for this Message.
Converted A conversion event has been received for this Message.
Clickthru The Message that included a link generated using Syniverse tracking service was clicked on or has been auto previewed
Failed The Message delivery failed and will not be retried.
Expired The Message was not delivered before the expiration date, so processing was canceled.
Scheduled The Message is scheduled to be delivered at a later date.
Test The Message is a test message and will not be delivered to recipients. The Message is created with the state when the "Test" flag is set to true in the Message Request Resource.
Paused The Message was sent with "Pause before transmitting" flag. The Message will not be sent until the state is moved back to "Created".
Deleted Indicates that the Sender Address is inactive and no longer usable. All implemented resources (e.g., short codes) have been released or de-provisioned. This is the end of the lifecycle of the channel. The Sender Address cannot be "undeleted." A new channel address must be created if the same address is to be reused.

Sending a Message

The REST API used to create a Message Request replies immediately with a reply which includes the (generated) Message Request ID of the submitted request. The actual delivery of the message is carried out separately. The Syniverse Communication API service will create a Message Resource for each recipient in the Message Request and associate these messages with the Message Request ID. The Syniverse Communication Gateway ensures the delivery of messages through the operator’s network or applicable delivery channel, to the recipient’s mobile device. For more information on how to send a message, please checkout the Quick start guide here

Receiving a Delivery Receipt 

Upon successful delivery of the message to the recipient, the Syniverse Communication API service will receive a confirmation from the Operator’s network, and we then relay the delivery confirmation (using the message request id and message id) to the callback URL of an Event Handler related to that application.

To address the possibility of application outages, the Syniverse Communication API service will continue to attempt to deliver the delivery receipt to the application via a defined interval, until it is able to connect to the application and issue the URL call and receive a http 200 response.

Inquiring on Message Delivery Status/Message History

The application can use the message request ID returned when a message request is submitted to inquire on the status of the Messages related to a Message Request. There are summary statistics that include the count of messages created, delivered, failed etc.

The application can also retrieve a list of all the messages that are associated with a given message request. The application can then check the status of each individual message.

The API structure also allows the application to use this to see past threads of communication, and the relationships between messages. It will allow the caller to fetch:

  • Messages related to a particular application.
  • Messages related to a specific contact, with the ability to show the threads/sequence of interaction, even when those threads cross multiple channels of communication, and/or involve multiple applications.
  • Combinations of the above.

Receiving a message from a recipient

The receipt of messages occurs directly from the operator network or media channel. Once the message is received by the Syniverse Communication API service, a store & forward approach is used to guarantee the delivery of the message.

Received messages are also stored in Syniverse Communication API service for asynchronous access at any later point in time and are available for polling from the messages resource when the customer system does not use the callback interface.

Customers can only receive messages to a privately provisioned Sender Address associated with their account.

Message Templates

Message Templates can be created and associated with a Sender Address. A message can then be sent with the corresponding name-value pairs to fill in the template. A Sender Address can be configured to enforce template use so that only messages that use a template can be sent using that Sender Address. To use a template, the message body will contain a special content type with a list of name value pairs as the content.

Templates can be created, updated, listed and deleted per the standard HTTP methods. Templates can be added to a Sender Address by setting the templateId field of the Sender Address.

Syniverse Message templates

The Syniverse CPaaS API service provides pre-configured application templates that are easy to use and are designed to help Customers integrate certain commonly used messaging use cases into their applications.

Pre-configured application templates can be used with a:

  • Syniverse Public Channel (Shortcode/Long code**).
  • Private Sender Address ( Dedicated Shortcode/Longcode**)

Please note that the pre-configured templates are available for US applications only and are mandatory to use a US public channel. In addition, a Public channel can be used to send to no more than 1000 recipient in a single message request.

Available Application Templates:

  • Two-Factor Authentication (2FA) and Password Reset
  • Event Notification (EN)- Several event type templates

Customer wishing to use Syniverse Communication API service’s pre-configured application templates shall ensure that they have a clearly defined T&C and privacy policy link. Syniverse shall manage consent needed for all application templates running on a Syniverse Communication API service shared shortcode or long code.

Our platform also provides capabilities for Customers to create their own Templates. For more information on how to use or create a template, please see Using SCG Templates

 

Link Tracking in Messages

Our Communication Gateway offers Link Tracking capabilities for Message Requests. URLs within messages can be flagged for tracking. For tracked URLs, the service will replace the URL with a shortened URL that points to the link tracking service. When the end user navigates to the tracked URL, the link tracking service will update the message status to "CLICKTHRU" to show that the link was clicked. There will also be a Message State Change event generated and sent to any delivery configuration endpoints for this application.

In order to flag a URL to be tracked, the url is passed as an argument to a #track directive in the message body.
Here is a sample message request with a tracked URL:

curl -X POST https://api.syniverse.com/scg-external-api/api/v1/messaging/message_requests \
-H "Authorization: Bearer [token]" \
-H "Content-Type: application/json" \
-d '{"from":"sender_id:5c96zku8zUTkxxxxxxxxxx",
"to":["+1346787XXXX"],
"body":"Please click here. #track(\"https://www.syniverse.com\")"}'

Attachments

The attachments entity represents the attachments which some media channels allow a message to contain. This might represent embedded image elements of an MMS, WeChat, Facebook, Push message, RCS or could represent email attachments.

Creating an attachment in the applicable API services is a two-step process. First, an attachment resource is created. Then the attachment data is sent via HTTP Post to the attachment "content" URI.

The attachment information can be accessed using the REST API or the attachment can be sent with a message using the attachmentID.

Once all message attachments are created, the list of attachment IDs created in this step, should be provided in the POST method that creates the Message Request. The attachment ID(s) are passed in the attachments attribute of the Message Request resource. Upon creation of the Message Request, all associated attachment instances will be updated by the Messaging API to reference the right Message ID. And the message will then be transmitted with the indicated attachments. For more information on how to use Attachment service, plese check out this article: How-to-use-attachments-with-omni-channel-messaging

Address Book

Contacts

A Contact represents a person/application/entity which the Syniverse Communication API service communicates with on behalf of applications. A contact contains one or more messaging addresses/IDs (e.g. Phone Number, email, Facebook ID) as well as other information about end users.

A Customer can send messages using Contact Ids. The Syniverse Communication API service will use the Contact ID to look up the corresponding address in order to deliver the message to the end user.

A Customer can also build recipient lists by specifying a query parameter that will be used to find matching contacts.

A Customer can also use a Message Template to create a custom message based on attributes found in the Contact Resource.

Contacts Groups

A contact group is simply a collection of Contacts meant to support bulk messaging operations (e.g. the ability to deliver messages to multiple contacts via a single API call.) Contact groups are owned by Customers and composed of Contacts. The contact_group resource includes the means to associate a group with a specific application, or a specific channel, but this is optional, and at the discretion and need of the user.

A Customer can send a message to multiple Contacts by creating a Contact Group and then specifying the Contact Group ID in the Message Request resource.

Dynamic Contact Groups

A Dynamic contact group is a collection of Contacts that is defined by a query string. The group members are any contacts that match the query at the time that the Group is used.

A Customer can send a message to multiple Contacts by creating a Dynamic Contact Group and then specifying the Contact Group ID in the Message Request resource.

Dynamic Group Queries

When a Dynamic Group is created, a query string is associated with the group.

This specification defines how Contact query strings are constructed. Contact Query strings can be associated with a Contact Group in order to define a dynamic group.

Allowed Contact Fields

A query string can contain any of the following fields.

  • external_id
  • status
  • first_name
  • last_name
  • birth_date
  • first_acquisition_date
  • last_acquisition_date
  • primary_mdn
  • primary_addr_line1
  • primary_addr_line2
  • primary_addr_city
  • primary_addr_zip
  • primary_addr_state
  • primary_email_addr
  • primary_social_handle

In addition to these fields, any of the “Fast Access Attributes” that have mappings may be used in a query. Use the form "fast_access.{Attribute Name}". For example if the Fast Access attribute name is FavoriteStore, then "fast_access.FavoriteStore" can be used in a query.

A query may contain up to 5 separate fields and 5 separate logical statements.

Query Structure

To match a single contact field, use the field name and the desired value separated with a ":".

Example:

{first_name: ‘Alice’)

This will match all contacts with first_name equal to "Alice".

Using Comparison Operators

List of comparison operators:

  • $eq: Equal to.
  • $gt: Greater than.
  • $gte: Greater than or equal to.
  • $lt: Less than.
  • $lte: Less than or equal to.
  • $ne: Not equal to.

Example:

{contact_birth_date.: {$lte: 1994-11-05T08:15:30-05:00} }
Using And Statements

Example:

{ contact_first_name: ‘Alice', contact_last_name: ‘Smith’ }
Using Or Statements

Example:

{ $or: [ { contact_first_name: ‘Alice’}, { contact_last_name: ‘Smith’ } ] }
Using And and Or Statements

Example:

{ birth_date.: {$lte: 1994-11-05T08:15:30-05:00} , $or: [ { contact_first_name: ‘Alice’}, { contact_last_name: ‘Smith’ } ] }

 

Text Language translate

The Communication API service offering allows customers to enhance communications with recipients by providing an optional Text language translation service. This feature when enabled as part of a Message request or based on a recipient language preference in the contact list, allows the body of the message to be translated to a language specified by the Customer.

Syniverse support translation of body text of any message across SMS in over 100 native languages globally. Currently, English is the source language that we translate from. Below are a list of languages that are supported and can be translated to:

Language Name Code Language Name Code Language Name Code
Afrikaans af Albanian sq Arabic ar
Azerbaijani az Basque eu Bengali bn
Belarusian be Bulgarian bg Catalan ca
Chinese Simplified zh-CN Chinese Traditional zh-TW Croatian hr
Czech cs Danish da Dutch nl
English en Esperanto eo Estonian et
Filipino tl Finnish fi French fr
Galician gl Georgian ka German de
Greek el Gujarati gu Haitian Creole ht
Hebrew iw Hindi hi Hungarian hu
Icelandic is Indonesian id Irish ga
Italian it Japanese ja Kannada kn
Korean ko Latin la Latvian lv
Malagasy mg Macedonian mk Malay ms
Maltese mt Norwegian no Persian fa
Polish pl Portuguese pt Romanian ro
Russian ru Serbian sr Slovak sk
Slovenian sl Spanish es Swahili sw
Swedish sv Tamil ta Telugu te
Thai th Turkish tr Ukrainian uk
Urdu ur Vietnamese vi Welsh cy
Pashto ps Zulu zu Uzbek uz
Lithuanian lt Myanmar (Burmese) my Armenian hy
Hmong hmn Kurdish ku Mongolian mn
Yiddish yi Punjabi pa Yoruba yo

For information on API resources to invoke this feature, please refer to the Omni-Channel API Reference documentation

Sample Language Translate request

curl -X POST https://api.syniverse.com/scg-external-api/api/v1/messaging/messages \
-H "Authorization: Bearer [token]" \
-H "Content-Type: application/json" \
-d '{"from":"sender_id:5c96zku8zUTkxxxxxxxxxx",
"to":"+1346787XXXX",
"body":"This is a test message",
"translate":true,
"src_language":"en",
"dst_language":"fr"}'

Error Codes and Definitions

 

For information on error codes and descriptions, please checkout the Voice and Messaging error codes 

 

Copyright © 2023 Syniverse Technologies