{
  1. Introduction
  2. Shared Features
  3. SMS
  4. WhatsApp
  5. RCS
  6. Viber
  7. Push
  8. Status Reports
  9. SMPP
  10. XML
  11. Http Get-requests
  12. Glossary
  13. Conversion API

Business Messaging API

The CM.com Business Messaging API enables you to send messages from your system to mobile phones all around the world. This RESTful API is the main interface between your application and the CM Platform and can be implemented to communicate via various communication channels - among others SMS, WhatsApp, RCS and Viber. We accept single messages, but also very high volumes. Core capability of this API is that it can cope with various communication channels and high throughput. The HTTP protocol is used, examples can be found in JSON and XML, though we advise to use JSON.

Pre requisites

To make use of our API for SMS, you need to be registered at CM.com and have your billing details set in your CM Wallet. This can be recurring billing via credit card (self service), or via alternative payment methods (signed business contract required).

In order to make use of communication channels like WhatsApp, Viber, or RCS, you are required to have access to the programs. This can be requested via CM.com and we will help you with the verification and activation when your request meets the terms and conditions of these additional services. For this too a billing account is required.

During the implementation you might have questions and we kindly refer to our Help Center documents to get more background information.

Authentication

All requests require your product token which, as a registered user, you can find on our platform in the Gateway app. It was also e-mailed to you after registration, e.g. 00000000-0000-0000-0000-000000000000. Callback URLs are also configured in this gateway app.

NOTE: Your product token is private information and should never be incorporated into webpages and/or mobile applications where it can be exposed to 3rd parties.

Encryption

Communication with the CM servers should be done using the TLS cryptographic protocol, version 1.1 or higher. Older security protocols such as TLSv1.0 and SSLv3 are not supported.

When making use of the WhatsApp Business API solution messages are encrypted on our platform. In our WhatsApp implementation guide we explain how this works. Encryption is a mandatory WhatsApp feature, implemented by CM.com. You don't have to do anything to enable this, it is part of the the WhatsApp account creation.

API endpoints

Our global gateway is accessible via one end point which we are load balancing over 2 platform locations in The Netherlands. To reduce latency, and/or be compliant to local legislation we also have platforms in London, South Africa and Shanghai. More information can be found in our Help Center.

  • Global Endpoint URL: https://gw.cmtelecom.com/v1.0/message
  • South African Endpoint URL: https://gw.cmtelecom.co.za/v1.0/message
  • Shanghai Endpoint URL: https://gw.cmtelecom.cn/v1.0/message
  • London Endpoint URL: https://gw-uk.cmtelecom.com/v1.0/message

Our API supports sending messages via HTTP. You can send a POST request containing a JSON or XML body. We strongly advice that you use JSON. The newer communication channels like RCS, WhatsApp and Viber are only supported via JSON. Information and examples about XML, SMPP and GET can be found at the end of our API documentation.

Channels

We have built our API in such away that you can use it for various communication channels. Currently we support:

  • SMS
  • WhatsApp
  • RCS
  • Viber
  • Push

These channel names should be specified in your request to to send a message. It is important you specify via which method you want to send out your messages as not defining any channel in a message will be interpreted as sending out an SMS.

Please note that for channels other than SMS, CM needs to configure the outgoing flows before you can use them.

Each channel comes with it's own rules and regulations from service providers and governments alike. You are responsible for following the rules and regulations for each channel that you use. Failure to do so might result in immediate termination of the service.

Receiving messages

When implementing communication channels like WhatsApp, that allow conversations with for instance a Bot or Service employee, there will be data flows from your systems (outbound/outgoing) as well as data which needs to be sent to your systems (inbound/incoming/MO).

To receive incoming messages (MO), you need to set a webhook and map the incoming API in your system. More information can be found in the API documentation of the Inbound webhook

Shared Features

Sample Requests

Below is an example of a Viber message:

{
    "messages": {
        "authentication": {
            "productToken": "your product token"
        },
        "msg": [{
            "body": {
                "content": "Message Text"
            },
            "to": [{
                "number": "00316012345678"
            }],
            "from": "TestSender",
            "allowedChannels": ["Viber"]
        }]
    }
}
from The name you want your end user to recognize you as. For instance your company name or phone number.
to Phone number of the recipient [array]
body Text content of the message you want to send
allowedChannels Communication channel via which you want to reach the user - can be SMS, Viber, RCS, or WhatsApp. When not filled, our default will be SMS.

Please note that the msg and to objects are arrays, and can contain multiple values resulting in multiple messages.

Phone numbers

Please use the following format to specify your phone numbers. Using this format is the best way for us to guarantee the correct delivery of your messages:

  • Start with 00
  • Country code
  • Phone number
  • No + sign
  • No spaces
  • No -

Not adhering to this convention might cause incorrect delivery!

CM.com example

The phone number of our office in The Netherlands is +31 (0)76 - 572 70 00 What we would enter via API: 0031765727000

Batch messages

It is possible to send multiple messages with one request, as described in the examples below. You can either declare multiple phone numbers to send the same message to each of the given phone numbers, or declare multiple different messages in one request.

{
    "messages": {
        "authentication": {
            "producttoken": "00000000-0000-0000-0000-000000000000"
        },
        "msg": [ {
                "allowedChannels":  ["Viber"],
                "from": "SenderName",
                "to": [{
                    "number": "00447911123456"
                },{
                    "number": "00447911123457"
                }],
                "body": {
                    "content": "Test message"
                }
            },
            {
                "allowedChannels":  ["SMS"],
                "from": "OtherSender",
                "to": [{
                    "number": "00447911123458"
                },{
                    "number": "00447911123459"
                }],
                "body": {
                    "content": "Other Test message"
                }
            }
        ]
    }
}

Channel fallback

Not all people have installed the popular communication applications in your geographic region. Neither are they always online or are the operator networks always available to deliver messages. To overcome this issue we have developed a fallback solution. By specifying multiple channels in the allowedChannels parameter, you can use another channel to deliver your messages when your first channel is not available or returning errors.

Example: specifying "allowedChannels": [ "WhatsApp", "SMS" ] acts as a filter on your configured channel routing. If WhatsApp returns a failure or a rejection for any reason, we will use SMS and the content in the body attribute to deliver an SMS instead. When a fallback is configured a channel will not retry delivery, but immediately fallback to the next channel.

Fallback is available for the channels:

  • WhatsApp
  • Push
  • RCS
  • Viber
  • SMS

If you would like to make use of fallbacks, please contact CM.com to configure multi channel routing for your account.

References and replies

For each batch of messages you send you can set a reference. To do so, add "reference": "your_reference" to any "msg" object in a request body. The given reference will apply to the messages sent to the numbers in the matching message.

  • The given reference will be used in the status reports and inbound replies for the message, so you can link the messages to the sent batch. For more information on status reports, see status report webhooks.
  • The given reference must be between 1 - 32 alphanumeric characters, and will not work using demo accounts.
  • References can be used to measure things like Conversion using the Conversion API.

Custom groupings

The custom grouping fields are optional fields that can be used to tag messages. These tags can be used by other products, like the Transactions API.

Applying custom grouping names to messages helps filter your messages. With up to three levels of custom grouping fields that can be set, subsets of messages can be further broken down. The custom grouping name can be up to 100 characters of your choosing.

You should limit the number of unique custom groupings to 1000.

This field is used for a wide variety of cases, but generically it helps you to group/tag your messages which helps you with analysis purposes. The following example demonstrates how to implement a reference and custom groupings in your JSON.

{
    "messages": {
        "authentication": {
            "producttoken": "00000000-0000-0000-0000-000000000000"
        },
        "msg": [ {
                "allowedChannels":  ["SMS"],
                "from": "SenderName",
                "to": [{
                    "number": "00447911123456"
                }],
                "body": {
                    "content": "Test message"
                },
                "reference": "your_reference",
                "customGrouping": "Campaign ABC",
                "customGrouping2": "Department XYZ",
                "customGrouping3": "Source 123",
            }
        ]
    }
}

Validity period

At all times we strive to deliver messages to the end-user as fast as possible. There can be several situations in which we cannot succeed in this goal. Someone might have switched off his/her phone, or might be in a remote location and does not have access to a network. When you have sent them a message it might be received later than you anticipated.

If you wish to specify a time at which a delayed message can be considered irrelevant, you can supply an absolute date & time or a relative offset in the validity field. Our system will consider the message as failed if it was not successfully delivered before that time. And via a Status Report we inform you this was the case.

The validity period is treated as a best-effort feature. Operators that are already processing the message, might not adhere to the validity period.

Our default validity time is 24 hours, and the maximum validity period is 72 hours.

This feature is supported in all communication channels, the behavior is the same. Though when you have set a fall-back process.

{
    "messages": {
        "authentication": {
            "producttoken": "00000000-0000-0000-0000-000000000000"
        },
        "msg": [ {
                "allowedChannels": ["SMS"],
                "from": "SenderName",
                "to": [{
                    "number": "00447911123456"
                }],
                "body": {
                    "content": "Test message"
                },
                "validity": "2017-04-20 11:50 GMT"
            }
        ]
    }
}

You can supply the time zone for the validity period using either of the following formats:

Absolute date and time:

  • 2017-04-20 11:50:05 GMT
  • 2017-04-20 11:50:05+8
  • 2017-04-20 11:55:05-07:00

If no time zone was specified, CE(S)T will be used. (CM local time)

Relative offset in hour (H) or minute (M)

  • 2h
  • 30m

You can set the validity in either hours or minutes. A combination of both is not supported. Any value less than 30 minutes cannot be guaranteed to work.

Rich Content

Channels like RCS and WhatsApp support messages with Rich Content.

Please note that not all communication channels offer the exact same features, and when they do the UI might vary per phone. To make use of submission of rich content you need to do some investigation work to ensure that all mobile devices can read what you are sending. We can help you defining and identifying this, please contact our support teams when you need a consult.

Suggestions/Features

One message can contain up to 11 suggestions to a user. How they are used depends on the scenario you want to built. Usually only 2 or 3 are seen by the end-user when opening the message.

Label The text the end user will see
Action OpenUrl / CreateCalendarEvent / Dial / ViewLocation / Reply

Depending on the action, certain fields are expected to complete the user flow.

OpenUrl

This is used to give the user an option to open a link. This can be an in-app link, which will only be shown when the app is installed.

URL The url the end user can open
{
    "suggestions": [
        {
            "action": "OpenUrl",
            "url": "market://details?id=cm.com",
            "label": "Install app"
        },
        {
            "action": "OpenUrl",
            "url": "https://docs.cmtelecom.com/bulk_sms/v1.0",
            "label": "SMS documentations"
        }
    ]
}

Create Calendar Event

When the user clicks on this icon, it opens the calendar app of the user to add the new appointment.

Calendar A calendar object

The calendar object contains the following fields.

StartTime The start of the appointment. For example "2018-02-05T07:00:00
EndTime The end of the appointment, for example "2018-02-05T08:00:00"
Description The description which will appear in the calendar app
Title The title of the appointment which will appear in the calendar app
{
    "action": "CreateCalendarEvent",
    "label": "Add to calendar",
    "calendar":
    {
        "startTime": "2018-02-05T00:00:00",
        "endTime": "2018-02-08T00:00:00",
        "description": "Calendar demo",
        "title": "Demo"
    }
}

Dial

RCS also provides options to make a phone call straight from the conversation. When you want to enable the user can call you, another team, or listen to a recorded spoken message, this suggestion can be applied. When clicked starts a new call, to the number you have inserted.

Dial A dial object

The dial object contains the following field.

PhoneNumber The number to call (in international format)
{
    "action": "Dial",
    "label": "Call us",
    "dial": {
        "PhoneNumber": "+310612345"
    }
}

ViewLocation

When you want to share a location, you can send this message. When the user receives it it opens the navigation app of the user with a pin at the specified location.

ViewLocation A view location object

View location objects contains the following fields:

Latitude (optional) The latitude in degrees
Longitude (optional *1) The longitude in degrees
SearchQuery (optional *1) Search for this location instead of using the latitude/longitude
Label (optional) The label to display at the pin

1. Either the search query or the latitude & longitude are required!

{
    "action": "viewLocation",
    "viewLocation": {
        "latitude": "51.603802",
        "longitude": "4.770821",
        "label": "CM HQ"
    },
    "label": "Open in maps"
}

Responses & Errors

When sending a request with an invalid msg part to the JSON gateway, it will continue to check the other to objects and msg objects available and send the correctly formatted values. In the JSON response, you can find details per message. With each message you receive the PhoneNumber of the failed message (if present), the accepted or rejected status, your reference for the message (if present), the amount of message parts we created for that message, and a description why the message was rejected (if present).

NOTE: The XML gateway and JSON gateway have different output, and respond very differently to errors. For XML responses, please see the section on XML communication.

Examples of responses of failed JSON requests:

Entire request incorrect:

Status: 400 Bad Request

{
  "details": "No account found for the given authentication",
  "errorCode": 101,  //See table "JSON POST Error codes" below
  "messages": []
}

Incorrect msg and a correct message:

Status: 200 OK

{
  "details": "Created 1 message(s)",
  "errorCode": 201, //See table "JSON POST Error codes" below
  "messages": [
    {
      "to": "00447911123456",
      "status": "Accepted",
      "reference": "your_reference_A",
      "parts": 1,
      "messageDetails": null,
      "messageErrorCode": 0 //See table "JSON POST Error codes" below
    },
    {
      "to": "00447911123457",
      "status": "Rejected",
      "reference": "your_reference_B",
      "parts": 0,
      "messageDetails": "A body without content was found",
      "messageErrorCode": 304 //See table "JSON POST Error codes" below
    }
  ]
}

All incorrect:

Status: 400 Bad Request

{
  "details": "Created 0 message(s)",
  "errorCode": 201,
  "messages": [
    {
      "to": "0044791112345a",
      "status": "Rejected",
      "reference": "your_reference_A",
      "parts": 0,
      "messageDetails": "Gsm '0044791112345a' is not a number.",
      "messageErrorCode": 303 //See table "JSON POST Error codes" below
    },
    {
      "to": "00447911123456",
      "status": "Rejected",
      "reference": null,
      "parts": 0,
      "messageDetails": "A body without content was found",
      "messageErrorCode": 304 //See table "JSON POST Error codes" below
    }
  ]
}

JSON POST responses

HTTP status Error text Remarks
405 (none) No HTTP GET or POST was used to send your request
500 "details": "Unknown Error" An unexpected error occurred. Check the provided values. Contact CM for support.
400 "details": "No account found for the given authentication" No account found for the provided product token.
400 "details": "Insufficient balance." Trial accounts only: You are out of trial messages. Order new messages via your dashboard. If you are a regular prepaid customer, you will be notified that you have run out of quota in a Status Report.
400 "details": "Message is unroutable." Your request could not be routed. Contact CM for support.
400 "details": "Invalid product token." Invalid or missing product token
400 "details": "A MESSAGES object requires at least one MSG object" A MSG object within the MESSAGE object is required and is missing.
400 "details": "Invalid JSON" The given JSON is malformed. Please validate your JSON syntax and try again.
200 "details": "Created [x] message(s)" An [x] amount of messages have been accepted. See the messages objects for further details.
- "messageDetails": "No FROM field found in a MSG object." The ‘FROM’ element is missing within the ‘MSG’ element
- "messageDetails": "Empty mobilenumber field, MT ignored" The Phone Number value for the TO element is missing
- "messageDetails": "Rejected: Gsm '[msisdn]' is not a number." The value for the TO element is not a valid Phone Number
- "messageDetails": "[Object] object is an invalid type, must be an array" The stated [Object] should be an array. Even if this contains one element.
- "messageDetails": "No body field was found" The ‘BODY’ element is missing within the ‘MSG’ element
- "messageDetails": "A body without content was found" The ‘BODY’ element is missing ‘CONTENT’

JSON POST Error codes

Error code Description
0 Ok
999 Unknown error, please contact CM support
101 Authentication of the request failed
102 The account using this authentication has insufficient balance
103 The product token is incorrect
201 This request has one or more errors in its messages. Some or all messages have not been sent. See MSGs for details
202 This request is malformed, please confirm the JSON and that the correct data types are used
203 The request's MSG array is incorrect
301 This MSG has an invalid From field (per msg)
302 This MSG has an invalid To field (per msg)
303 This MSG has an invalid Phone Number in the To field (per msg,)
304 This MSG has an invalid Body field (per msg)
305 This MSG has an invalid field. Please confirm with the documentation (per msg)
401 Message has been spam filtered
402 Message has been blacklisted
403 Message has been rejected
500 An internal error has occurred

SMS

Unicode

Please note that there are a few limitations to using unicode encoded messages:

  • Unicode messages can contain up to 70 characters. In the case of multipart messages, this becomes 66 characters per part.
  • You will need to POST the XML or JSON file. A HTTP GET request cannot handle the Unicode characters
  • Another note is that not all operators in the world are able to handle Unicode messages, so you will need to test for which operators it works. If you want to have support with this our TEXTER solution might be a solution for you.

Auto detect encoding

It possible to let our gateway do the encoding detection for you. In case it detects characters that are not part of the GSM character set, the message will be delivered as Unicode. Any existing DCS value will be ignored. If the message contains more than 70 characters in Unicode format it will be split into a multipart message. You can limit the number of parts by setting the maximum number of message parts (see also the section on Multipart below).

{
    "messages": {
        "authentication": {
            "producttoken": "00000000-0000-0000-0000-000000000000"
        },
        "msg": [ {
                "allowedChannels":  ["SMS"],
                "from": "SenderName",
                "to": [{
                    "number": "00447911123456"
                }],
                "minimumNumberOfMessageParts": 1,
                "maximumNumberOfMessageParts": 8,
                "body": {
                    "type": "AUTO",
                    "content": "Κείμενο διαθέσιμο σε όλες τις γλώσσες"
                }
            }
        ]
    }
}

Custom DCS

By default our gateway interprets SMS messages as if sent with the standard 7 bit GSM encoding. You use the DCS (data coding scheme) parameter to indicate the type of message you are sending. If you set DCS to '0' or do not include the parameter, the messages uses standard GSM encoding. If you want to send messages using e.g. Arabic, Cyrillic of Greek characters you will need to use the unicode UCS2 encoding. To set your message up for unicode messaging include <DCS>8</DCS> in your <MSG>-element, or if you're using JSON "dcs": 8 in a msg object. See the examples below.

You use the DCS (data coding scheme) parameter to indicate the type of message you are sending. If you set DCS to '0' or do not include the parameter, the messages uses standard GSM encoding. If DCS is set to '8' the message will be encoded using Unicode UCS2. View the Unicode paragraph for more information.|

{
    "messages": {
        "authentication": {
            "producttoken": "00000000-0000-0000-0000-000000000000"
        },
        "msg": [ {
                "allowedChannels":  ["SMS"],
                "from": "SenderName",
                "to": [{
                    "number": "00447911123456"
                }],
                "dcs": 8,
                "body": {
                    "content": "Κείμενο διαθέσιμο σε όλες τις γλώσσες"
                }
            }
        ]
    }
}

Multipart

When your message is longer than 160 characters, we call such message a multipart or concatenated message. Technically the gateway will first check if an SMS is larger than 160 characters, if so, the message will be cut into multiple 153 characters parts.

Please note that there are a few limitations to using multipart messages:

  • Each message part can only contain up to 153 characters. (rest of the message is used to match the separate parts in the right order together again)
  • The SMS standard theoretically permits up to 255 message parts (which could mean you would send messages of 153 times 255 = 39.000 characters). In practice you should try to limit your message to 8 message parts – thus 153 time 8 = 1.224 characters.
  • When sending multi-part messages, pricing is done per message of 153 characters, hence sending multipart message can have impact your budget.
  • Another note is that not all operators in the world are able to handle multipart messages, so you will need to test for which operators it works. If you want to have support with this our TEXTER solution might be a solution for you. More information can be found in the TEXTER solution product page.
  • New services like RCS, WhatsApp do not work with this limitation. When you want to send large messages is might be worthwhile to investigate alternatives.
{
    "messages": {
        "authentication": {
            "producttoken": "00000000-0000-0000-0000-000000000000"
        },
        "msg": [ {
                "allowedChannels":  ["SMS"],
                "from": "SenderName",
                "to": [{
                    "number": "00447911123456"
                }],
                "minimumNumberOfMessageParts": 1,
                "maximumNumberOfMessageParts": 8,
                "body": {
                    "content": "Using these settings we can send SMS messages that contain more than 160 characters as if it is one message. Please do note that this limits the length of one message to 153 characters."
                }
            }
        ]
    }
}

WhatsApp

This chapter of our API Documentation is designed for customers whom have been granted access to WhatsApp Business API. It is important that you request access to this program via our portal. Without this approval you can not make use of this part of the API. When you have no access to the WhatsApp for Business program yet, please contact CM.com via our WhatsApp product page.

Note: since WhatsApp for Business is used for 2-way communication (chat) it is important to also implement the Inbound flow using our API documentation of the Inbound webhook. For the end user, making use of WhatsApp is free of charge, with the exception of their data usage when there is no wifi. Hence consider the message size you send to your user. We strongly advise not to send files larger than 1 MB, and for a conversation not to exceed 20Mb.

Message encryption

When making use of the WhatsApp Business API solution messages are encrypted on our platform. In our WhatsApp implementation guide we explain how this works. Encryption is a mandatory WhatsApp feature, implemented by CM.com. You don't have to do anything to enable this, it is part of the the WhatsApp account creation.

Sending a WhatsApp message

For service requests, users usually initiate a conversation and will reach out to you. To link incoming messages, to your outbound messages the phone number field is used.

Message example

{
    "messages": {
        "authentication": {
            "productToken": "your product token"
        },
        "msg": [{
            "body": {
                "content": "Message Text"
            },
            "to": [{
                "number": "00316012345678"
            }],
            "from": "TestSender",
            "allowedChannels": ["WhatsApp"]
        }]
    }
}

URL previews

Any URLs present in the message text of a WhatsApp message will be automatically recognized by the clients as links. Additionally, the first URL encountered in a text message will generate a URL preview. For this it is required that the URL starts with http:// or https://

A URL preview can contain a title, a message and a small fragment of text. These elements are automatically retrieved from the destination website. To support this preview, the destination website needs to have implemented the Open Graph Protocol.

The URL preview is retrieved by the WhatsApp software running on the CM.com side, before being send to the client. This is for privacy reasons.

References

When you have sent out a notification and want to link that to incoming information you can connect those via REFERENCES.

Template

To send a message to a user first a template must be used. These templates must be setup and approved before they can be used. You can request templates via CM.com (see implementation manual). Once a template is approved you can use the template namespace and name to send a message. There are parameters to personalize/actualize the message. The template message must have the exact same number of variables as the template has. The same template can be set-up in multiple languages, hence we also need a language parameter.

A user must have opted in. As you know a user must first consent to receive messages in WhatsApp by opting in. The opt-in must be an active opt-in. This means it must be triggered by a user action, such as entering a phone number or checking a box to indicate consent.

See also Facebook's opt-in guide.

Example message

{
    "messages": {
        "authentication": {
            "producttoken": "your product token"
        },
        "msg": [{
            "from": "CM.com",
            "to": [{
                    "number": "0031612345678"
                }
            ],
            "body": {
                "TYPE": "AUTO",
                "content": "This is a WhatsApp message"
            },
            "allowedChannels": ["WhatsApp"],
            "RichContent": {
                "conversation":
                [{
                    "template": {
                        "whatsapp": {
                            "namespace": "your template id here",
                            "element_name": "TEMPLATE_NAME",
                            "language": {
                                "policy": "fallback",
                                "code": "en_US"
                            },
                            "localizable_params": [{
                                    "default": "Name"
                                }, {
                                    "default": "Event"
                                }, {
                                    "default": "Saturday 6, July",
                                    "date_time": {
                                        "component": {
                                            "day_of_week": "Saturday",
                                            "day_of_month": 6,
                                            "year": 2019,
                                            "month": 7,
                                            "hour": 13,
                                            "minute": 0
                                        }
                                    }
                                }, {
                                    "default": "€10.50",
                                    "currency": {
                                        "currency_code": "EUR",
                                        "amount_1000": 10500
                                    }
                                }
                            ]
                        }
                    }
                }]
            }
        }]
    }
}

A template object contains a 'whatsapp' object, which corresponds to the template object in the WhatsApp for Business docs

Field Description Required
namespace The namespace that will be used, will be provided to you after the template is approved Yes
element_name The element name of the template that will be used, will be provided to you after the template is approved Yes
language Specifies the language, see below for object definition Yes
localizable_params The parameters to personalize the templated message Yes

Language

Field Description Required
policy Use 'fallback' to allow the message to be received even if the user has a different language setting, use 'deterministic' to only send the message when the user has the specified language setup Yes
code The code of the language or locale to use — Accepts both language and language_locale formats (e.g., en and en_US). Yes

Media messages

In WhatsApp the following media types are supported:

Type Supported file types to send
image JPG, JPEG, PNG image/jpg
image/jpeg
image/png
video MP4 (see notes) video/mp4
audio AAC, M4A, AMR, MP3, OGG, OPUS audio/acc
audio/m4a
audio/amr
audio/mp3
audio/ogg
audio/opus
document PDF, DOC(X), PPT(X), XLS(X) document/pdf
document/doc
document/docx
document/ppt
document/xls

Notes:

  • The maximum file size for uploaded media is 100MB.
  • For video only H.264 video codec and AAC audio codec is supported.

Media object contains the following fields:

Term Description
MediaName The caption of the image or video (not supported for audio).
MediaUri The location of the image, audio or video.
MimeType The mime type of the image, audio or video.
{
    "conversation": [
        {
            "media": {
                "mediaName": "conversational-commerce",
                "mediaUri": "https://www.cm.com/cdn/web/nl-nl/blog/conversational-commerce.jpg",
                "mimeType": "image/jpg"
            }
        }
    ]
}

Location messages

To send a location to a user use the location object, which contains the following fields:

Latitude The latitude in degrees
Longitude The longitude in degrees
SearchQuery The address to display
Label The label to display at the pin

Example

{
    "conversation": [
        {
            "location": {
                "latitude": "51.603802",
                "longitude": "4.770821",
                "label": "CM HQ",
                "searchQuery": "Konijnenberg 30"
            }
        }
    ]
}

Contacts

To send one or more contacts to a user use the Contacts array, which contains the fields described in WhatsApp for Business docs.

Note that only the name.formatted_name is required.

Example

{
    "conversation": [
        {
            "contacts": [
                {
                    "addresses": [
                        {
                            "city": "Breda",
                            "country": "Netherlands",
                            "country_code": "NL",
                            "street": "Konijnenberg 30",
                            "type": "WORK",
                            "zip": "4825 BD"
                        }
                    ],
                    "name": {
                        "formatted_name": "CM Developer"
                    }
                }
            ]
        }
    ]
}

RCS

An alternative for SMS, is RCS. To deliver the message also telecom operators are being used, though now you can send rich content instead of pure text messages. Unfortunately RCS is not yet available in each country. When you would be interested to learn more, and get access to resources to assist with the set-up please contact us via our RCS Business Messaging product page.

We are working on updating our RCS documentation.

Viber

Viber is growing in popularity and offers besides transactional messaging also the possibility to send marketing messages. Our platform offers you several other tools and products that you can freely use, also with Viber as communication channel. Examples here are our Analytics, Customer Contact application and Campaign tooling. Viber is secure communication via end-to-end encryption. Please be aware that Viber needs verify the legitimacy of your business and your rational for use. You can request access via our website.

Via Viber you can send text, images and URLs (in the form of buttons). If you would like to send locations or date indicators you can include that in the message and the phone will interpret those. Due to Viber imposed restrictions, sending an image and text in a single request is not supported. The following combinations are supported in a single request:

  • Text
  • Image
  • Text and button
  • Text, image and button

Message example

{
    "messages": {
        "authentication": {
            "productToken": "your product token"
        },
        "Msg": [
            {
                "body": {
                    "content": "SMS fallback text"
                },
                "richcontent": {
                    "conversation": [
                        {
                            "text": "Viber message text"
                        },
                        {
                            "media": {
                                "mediaName": "viber-example.png",
                                "mediaUri": "https://www.cm.com/cdn/web/viber-message-festival.png",
                                "mimeType": "image/PNG"
                            }
                        }
                    ],
                    "suggestions": [
                        {
                            "action": "Openurl",
                            "label": "Visit cm.com",
                            "url": "https://www.cm.com"
                        }
                    ]
                },

            "to": [{
                "number": "00316012345678"
            }],
            "from": "TestSender",
            "allowedChannels": ["Viber"]
        }]
    }
}

Push

Hybrid Messaging is an intelligent way to deliver phone number based messages via Push or SMS through the existing CM Messaging gateway when your preferred option did not work.

Prerequisites:

  • Make sure to implement the Hybrid SDK in your app
  • Create the app in the App manager, select the messaging type, upload the Apple certificates and/or Android keys in the App manager.
  • The App manager will give you an App Key and App Secret, the App Key is needed in the request to the gateway.

The example request below has the allowed channel "Push". This means the message will be restricted to only taking "Push" routes.

{
    "messages": {
        "authentication": {
            "producttoken": "00000000-0000-0000-0000-000000000000"
        },
        "msg": [ {
                "from": "SenderName",
                "to": [{
                    "number": "00447911123456"
                }],
                "body": {
                    "content": "This message defines allowed channels"
                },
                "allowedChannels": ["Push"],
                "appKey": "00000000-0000-0000-0000-000000000000"
            }
        ]
    }
}

This example request will first attempt to deliver a message using Push messaging but will fallback to SMS if the Push message cannot be delivered for any reason.

{
    "messages": {
        "authentication": {
            "producttoken": "00000000-0000-0000-0000-000000000000"
        },
        "msg": [ {
                "allowedChannels": [
                    "Push",
                    "SMS"
                ],
                "from": "SenderName",
                "to": [{
                    "number": "00447911123456"
                }],
                "appKey": "00000000-0000-0000-0000-000000000000",
                "body": {
                    "content": "This message will be delivered as a push message."
                }
            }
        ]
    }
}

Status report webhook

Once you have send out messages via our Business Messaging API, you likely want to receive status updates in return. These status updates will inform you how successful a campaign has been. Whom has received your message well, or in case of failure when a fallback has been applied. You can view and receive those statuses either on the CM-platform in the messaging log or in your own system via a Webhook.

  • API/Webhook - data in your own systems, development required, where also you need to adhere to GDPR.
  • Messaging log – data in CM's own platform, accessible for you 24/7, no development required, GDPR compliant.

There are no additional cost to use either one. The Messaging platform has the option to communicate with a web server whenever a message had an updated status. The status reports will be communicated using a HTTP POST request.

Configure status reports

You can configure your status report webhook in the 'Messaging Gateway'-app. Please refer to this article in our Help center for more information. When configuring the webhook URL, you must ensure this URL returns HTTP status code 200(OK) on the test call we make. If our call to the webhook fails, we will not use the provided URL.

Parameter specification - xml

Name Format Description
Created Datetime The moment when the status report was registered on CM.com's platform
Send Datetime The moment when the status report was sent to customer's/your endpoint
To String The recipient of the message, such as the telephone number of the message recipient or another identifier
Status Integer The code describing the current state of the message.
0 = accepted by the operator
1 = rejected by CM or operator
2 = delivered
3 = failed (message was not and will not be delivered)
4 = Read (Not for SMS, only other channels)
Standard Error String The description of the error if the message is in an error-state
Status Description String The description of the current state of the message
Channel String The used communication method via which the status report was received – ie. sms, whatsapp, viber.
Operator String The Mobile Operator of the recipient - if relevant
Reference String The message reference which can be provided by the customer in the outbound message (see business messaging API)
CustomGrouping
CustomGrouping2
CustomGrouping3
String The custom groupings set for this Outbound Message (MT) (see business messaging API)

Note:

  • Date/time values are formatted as "yyyy-mm-ddThh:ii:ss" and provided in CEST.

SMPP

Clients can use SMPP to deliver and receive mobile terminated (MT) messages, mobile originated (MO) messages and delivery reports (DLR messages) to and from the CM SMS gateway. CM supports SMPP protocol version 3.4. If you would like to get the South African SMPP settings, please reach out to your Account Manager.

Delivery receipts

Delivery receipts are sent in the short_message field of a deliver_sm or the message_payload TLV of a data_sm PDU, as per account configuration. In both cases, the message state is available as a message_state TLV attached to the PDU as well as in the actual receipt. Use whichever is more convenient.

Global description

The following format is used:

id:IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII submit date:yyyyMMddHHmmss done date:yyyyMMddHHmmss stat:SSSSSSS err:EEE

The number and order of fields is fixed, and they are separated by a single ASCII space. It is unwise to depend on this, however; for extendibility, you should not assume any number or ordering of fields and accept arbitrary whitespace as separator.

Similarly, though sizes are specified, strings not of fixed length may vary in size -- the specified size only reflects the maximum returned size as currently implemented. In no case will the total message length exceed 255 characters, however.

Field breakdown

Field Size Type Description
id 32 string The message ID allocated to the message by the SMSC when originally submitted.
stat 7 Fixed length string The final status of the message as specified in Table Message state values or ENROUTE for receipts of pending messages.
submit date 14 Fixed length string The time and date at which the short message was sent. Formatted: yyyyMMddHHmmss
done date 14 Fixed length string The time and date at which the short message reached its final state. Formatted: yyyyMMddHHmmss

Message state values

Message state Final message states Description (from SMPP standard) CM specific description
DELIVERED DELIVERD Message is delivered to destination. Message was delivered at the handset.
EXPIRED EXPIRED Message validity period has expired.
DELETED DELETED Message has been deleted. Not used.
UNDELIVERABLE UNDELIV Message is undeliverable. Message was not delivered at the handset.
ACCEPTED ACCEPTD Message is in accepted state (i.e. has been manually read on behalf of the subscriber by customer service). Message has been buffered at the operator network.
UNKNOWN UNKNOWN Message is in an invalid state. Not used.
REJECTED REJECTD Message is in a rejected state. Message was not accepted by the server.

Notable differences with the example format given in the standard:

  • Strings are not zero-terminated but whitespace-separated. As such, no string contains whitespace.
  • The message id is not a 10-digit decimal but a 32-character string.
  • The date specifies a 4-digit year, not a 2-digit one, and includes seconds.
  • The 'sub', 'dlvrd' and 'text' fields are not available.

Single connection

In order to use a single connection to send messages for all operators and tariffs the following proprietary TLVs are supported for both the DELIVER_SM PDUs and the SUBMIT_SM PDUs (please note that the tariff TLV is not yet used for DELIVER_SM PDUs). The "basic unit" of the tariff field is presently cents for all accounts.

Field Size octets Type Description
Parameter tag 2 Integer 0x1401
Length 2 Integer Length of Value part
Value 1-7 C-Octet string(Decimal) MCC/MNC of operator
Field Size octets Type Description
Parameter tag 2 Integer 0x140A
Length 2 Integer Length of Value part
Value 1-6 C-Octet string(Decimal) Tariff in basic unit

Error Codes:

SMPP Documentation pdf

XML Protocol

XML is only available for our SMS services.

API endpoints

More information can be found in our Help Center.

  • Global XML Endpoint URL: https://gw.cmtelecom.com/gateway.ashx
  • South African XML Endpoint URL: https://gw.cmtelecom.co.za/gateway.ashx

Values should be XML encoded and XML element names are in capitals. The following characters must be escaped in the XML body:

Character Escape value
" &quot;
' &apos;
< &lt;
> &gt;
& &amp;

POST requires a valid XML document, UTF-8 encoded. Values should be XML encoded and XML element names are in capitals. The following characters must be escaped in the XML body:

Character Escape value
" &quot;
' &apos;
< &lt;
> &gt;
& &amp;

A POST containing JSON should be sent to a different URL. JSON keys are case insensitive.

<?xml version="1.0" encoding="utf-8"?>
<MESSAGES>
  <AUTHENTICATION>
    <PRODUCTTOKEN>00000000-0000-0000-0000-000000000000</PRODUCTTOKEN>
  </AUTHENTICATION>
  <MSG>
    <CHANNEL>SMS</CHANNEL>
    <FROM>SenderName</FROM>
    <TO>00447911123456</TO>
    <BODY>Test message</BODY>
  </MSG>
</MESSAGES>

Batches - xml

<?xml version="1.0"?>
<MESSAGES>
  <AUTHENTICATION>
    <PRODUCTTOKEN>00000000-0000-0000-0000-000000000000</PRODUCTTOKEN>
  </AUTHENTICATION>
  <MSG>
    <CHANNEL>SMS</CHANNEL>
    <FROM>SenderName</FROM>
    <TO>00447911123456</TO>
    <TO>00447911123457</TO>
    <BODY>Test message</BODY>
  </MSG>
  <MSG>
    <CHANNEL>SMS</CHANNEL>
    <FROM>OtherSender</FROM>
    <TO>00447911123458</TO>
    <TO>00447911123459</TO>
    <BODY>Other Test message</BODY>
  </MSG>
</MESSAGES>

References - xml

<?xml version="1.0"?>
<MESSAGES>
  <AUTHENTICATION>
    <PRODUCTTOKEN>00000000-0000-0000-0000-000000000000</PRODUCTTOKEN>
  </AUTHENTICATION>
  <MSG>
    <CHANNEL>SMS</CHANNEL>
    <FROM>SenderName</FROM>
    <TO>00447911123456</TO>
    <BODY>Test message</BODY>
    <REFERENCE>your_reference</REFERENCE>
  </MSG>
</MESSAGES>

Unicode - xml

<?xml version="1.0"?>
<MESSAGES>
  <AUTHENTICATION>
    <PRODUCTTOKEN>00000000-0000-0000-0000-000000000000</PRODUCTTOKEN>
  </AUTHENTICATION>
  <MSG>
    <CHANNEL>SMS</CHANNEL>
    <FROM>SenderName</FROM>
    <TO>00447911123456</TO>
    <DCS>8</DCS>
    <BODY>Κείμενο διαθέσιμο σε όλες τις γλώσσες</BODY>
  </MSG>
</MESSAGES>

Auto-detection Unicode

<?xml version="1.0"?>
<MESSAGES>
  <AUTHENTICATION>
    <PRODUCTTOKEN>00000000-0000-0000-0000-000000000000</PRODUCTTOKEN>
  </AUTHENTICATION>
  <MSG>
    <CHANNEL>SMS</CHANNEL>
    <FROM>SenderName</FROM>
    <TO>00447911123456</TO>
    <MINIMUMNUMBEROFMESSAGEPARTS>1</MINIMUMNUMBEROFMESSAGEPARTS>
    <MAXIMUMNUMBEROFMESSAGEPARTS>8</MAXIMUMNUMBEROFMESSAGEPARTS>
    <BODY TYPE="AUTO">Κείμενο διαθέσιμο σε όλες τις γλώσσες</BODY>
  </MSG>
</MESSAGES>

Multipart - xml

<?xml version="1.0"?>
<MESSAGES>
  <AUTHENTICATION>
    <PRODUCTTOKEN>00000000-0000-0000-0000-000000000000</PRODUCTTOKEN>
  </AUTHENTICATION>
  <MSG>
    <CHANNEL>SMS</CHANNEL>
    <FROM>SenderName</FROM>
    <TO>00447911123456</TO>
    <MINIMUMNUMBEROFMESSAGEPARTS>1</MINIMUMNUMBEROFMESSAGEPARTS>
    <MAXIMUMNUMBEROFMESSAGEPARTS>8</MAXIMUMNUMBEROFMESSAGEPARTS>
    <BODY>Using these settings we can send SMS messages that contain more than 160 characters as if it is one message. Please do note that this limits the length of one message to 153 characters.</BODY>
  </MSG>
</MESSAGES>

Custom Grouping - xml

<?xml version="1.0"?>
<MESSAGES>
  <AUTHENTICATION>
    <PRODUCTTOKEN>00000000-0000-0000-0000-000000000000</PRODUCTTOKEN>
  </AUTHENTICATION>
  <MSG>
    <CHANNEL>SMS</CHANNEL>
    <FROM>SenderName</FROM>
    <TO>00447911123456</TO>
    <BODY>This message uses custom groupings</BODY>
    <CUSTOMGROUPING>Campaign ABC</CUSTOMGROUPING>
    <CUSTOMGROUPING2>Department XYZ</CUSTOMGROUPING2>
    <CUSTOMGROUPING3>Source 123</CUSTOMGROUPING3>
  </MSG>
</MESSAGES>

Push - xml

<?xml version="1.0"?>
<MESSAGES>
  <AUTHENTICATION>
    <PRODUCTTOKEN>00000000-0000-0000-0000-000000000000</PRODUCTTOKEN>
  </AUTHENTICATION>
  <MSG>
    <CHANNEL>SMS</CHANNEL>
    <FROM>SenderName</FROM>
    <TO>00447911123456</TO>
    <BODY>This message defines allowed channels</BODY>
    <ALLOWEDCHANNELS>Push</ALLOWEDCHANNELS>  
    <APPKEY>00000000-0000-0000-0000-000000000000</APPKEY>  
  </MSG>
  </MSG>
</MESSAGES>

Hybrid - xml

<?xml version="1.0"?>
<MESSAGES>
  <AUTHENTICATION>
    <PRODUCTTOKEN>00000000-0000-0000-0000-000000000000</PRODUCTTOKEN>
  </AUTHENTICATION>
  <MSG>
    <CHANNEL>Push</CHANNEL>
    <FROM>SenderName</FROM>
    <TO>00447911123456</TO>
    <APPKEY>00000000-0000-0000-0000-000000000000</APPKEY>
    <BODY>This message will be delivered as a push message.</BODY>
  </MSG>
</MESSAGES>

Responses & Errors - xml

When sending a request with an invalid part to the XML gateway, NO MESSAGES are created and the entire request is rejected. You will receive a plain text response with details why the request was rejected.

Example response of a failed XML request:

Status: 200 OK

Error: ERROR No account found for the given authentication

XML POST responses

HTTP status Error text Remarks
400 (none) No HTTP GET or POST was used to send your request
200 Error: ERROR Unknown error An unexpected error occurred. Check the provided values. Contact CM for support.
200 (empty) The request was accepted
200 Error: ERROR No account found for the given authentication No account found for the provided product token.
200 Error: ERROR Insufficient balance. Trial accounts only: You are out of trial messages. Order new messages via your dashboard. If you are a regular prepaid customer, you will be notified that you have run out of quota in a Status Report.
200 Error: ERROR Message is unrouteable. Your request could not be routed. Contact CM for support.
200 Error: ERROR Invalid product token. Invalid or missing product token
200 Error: ERROR No FROM field found in a MSG node. The ‘FROM’ element is missing within the ‘MSG’ element
200 Error: ERROR A MESSAGES node requires at least one MSG node A MSG node within the MESSAGE node is required and is missing.
200 Error: ERROR No phone numbers found. Message will not be sent. The Phone Number value for the TO element is missing
200 Error: ERROR Rejected: Gsm '<msisdn>' is not a number. The value for the TO element is not a valid Phone Number

Errors

Error code Short description Full description
5 Message not delivered at third party The message has been confirmed as undelivered but no detailed information related to the failure is known.
7 Message not delivered at operator because recipient has insufficient credit Temporary - Used to indicate to the client that the message has not yet been delivered due to insufficient subscriber credit but is being retried within the network.
8 Message expired at third party Temporary - Used when a message expired (could not be delivered within the life time of the message) within the operator SMSC but is not associated with a reason for failure.
20 Message not delivered because of a malformed request Used when a message in its current form is undeliverable.
21 Message expired at operator Temporary - Only occurs where the operator accepts the message before performing the subscriber credit check. If there is insufficient credit then the operator will retry the message until the subscriber tops up or the message expires. If the message expires and the last failure reason is related to credit then this error code will be used.
22 Message not delivered at operator because recipient has insufficient credit Temporary - Only occurs where the operator performs the subscriber credit check before accepting the message and rejects messages if there are insufficient funds available.
23 Message not delivered because of an incorrect recipient number (invalid/blacklisted/barred) Used when the message is undeliverable due to an incorrect / invalid / blacklisted / permanently barred Phone Number for this operator. This Phone Number should not be used again for message submissions to this operator.
24 Message not delivered because the recipient was unreachable Temporary - Used when a message is undeliverable because the subscriber is temporarily absent, e.g. his/her phone is switch off, he/she cannot be located on the network.
25 Message not delivered at third party Temporary - Used when the message has failed due to a temporary condition in the operator network. This could be related to the SS7 layer, SMSC or gateway.
26 Message not delivered because of a temporary handset issue (sim card full/memory exceeded/SME busy) Temporary - Used when a message has failed due to a temporary phone related error, e.g. SIM card full, SME busy, memory exceeded etc. This does not mean the phone is unable to receive this type of message/content (refer to error code 27).
27 Message not delivered because of a permanent handset issue (unable to receive SMS) Permanent - Used when a handset is permanently incompatible or unable to receive this type of message.
28 Message not delivered because submission speed is too high (throttling errors) Used if a message fails or is rejected due to suspicion of SPAM on the operator network. This could indicate in some geographies that the operator has no record of the mandatory MO required for an MT.
29 Message not delivered because content is not permitted Permanent - Used when this specific content is not permitted on the network / shortcode.
30 Message not delivered because the set spend limit is reached Temporary - Used when message fails or is rejected because the subscriber has reached the predetermined spend limit for the current billing period.
31 Message not delivered because the recipient was suspended from premium services Used when the Phone Number is for a valid subscriber on the operator but the message fails or is rejected because the subscriber is unable to be billed, e.g. the subscriber account is suspended (either voluntarily or involuntarily), the subscriber is not enabled for bill-tophone services, the subscriber is not eligible for bill-to-phone services, etc.
33 Message not delivered because of parental lock Used when the subscriber cannot receive adult content because of a parental lock.
34 Message not delivered because age check failure Permanent - Used when the subscriber cannot receive adult content because they have previously failed the age verification process.
35 Message not delivered because age check missing Temporary - Used when the subscriber cannot receive adult content because they have not previously completed age verification.
36 Message not delivered because age check unavailable Temporary - Used when the subscriber cannot receive adult content because a temporary communication error prevents their status being verified on the age verification platform.
37 Message not delivered because recipient is in national Do-Not-Call Register (for example, the Dutch SMS DienstenFilter and Chinese DnD list) The Phone Number is on the national blacklist

HTTP GET protocol

We also maintain a gateway interface that can be addressed using a HTTP GET method. This call is limited in its features and only supports the basic parameters (FROM, TO, BODY and REFERENCE), options such as concatenation (multipart), unicode, and hybrid messaging are not supported. We advise to use our HTTP POST call if possible.

https://gw.cmtelecom.com/gateway.ashx?producttoken=00000000-0000-0000-0000-000000000000&body=Example+message+text&to=00447911123456&from=SenderName&reference=your_reference

Parameter Description
PRODUCTTOKEN Required. This is the product token that was sent to you by email. Example: 00000000-0000-0000-0000-000000000000'
MSG Required. The msg-tag signals the start of a message and should comprise of at least a from, to and body-tag. One HTTP-call can support up to 1000 msg elements.
FROM Required. This is the sender name. The maximum length is 11 alphanumerical characters or 16 digits. Example: 'CM Telecom'
TO Required. This is the destination mobile number. Restrictions: this value should be in international format. A single mobile number per request. Example: '00447911123456'
BODY Required. This is the message text. Restrictions: the maximum length is 160 characters.
DCS HTTP POST only. You use the DCS (data coding scheme) paramater to indicate the type of message you are sending. If you set DCS to '0' or do not include the parameter, the messages uses standard GSM encoding. If DCS is set to '8' the message will be encoded using Unicode UCS2. View the Unicode paragraph for more information.
REFERENCE Here you can include your message reference. This information will be returned in a status report so you can match the message and it's status. It should be included in the XML when posting. Restrictions: 1 - 32 alphanumeric characters and reference will not work for demo accounts.
MINIMUMNUMBEROFMESSAGEPARTS / MAXIMUMNUMBEROFMESSAGEPARTS Used when sending multipart or concatenated SMS messages and always used together. Indicate the minimum and maximim of message parts that you allow the gateway to send for this message (also see Multipart). Technically the gateway will first check if a message is larger than 160 characters, if so, the message will be cut into multiple 153 characters parts limited by these parameters.
APPKEY Use an APPKEY for Hybrid Messaging purposes. If an APPKEY is added the gateway will deliver according the settings defined in the App Manager.

Responses & Errors

HTTP status Error text Remarks
400 (none) No HTTP GET or POST was used to send your request
200 Error: ERROR Unknown error An unexpected error occurred. Check the provided values. Contact CM for support.
200 (empty) The request was accepted
200 Error: ERROR No account found for the given authentication No account found for the provided product token.
200 Error: ERROR Insufficient balance. Trial accounts only: You are out of trial messages. Order new messages via your dashboard. If you are a regular prepaid customer, you will be notified that you have run out of quota in a Status Report.
200 Error: ERROR Message is unrouteable. Your request could not be routed. Contact CM for support.
200 Error: ERROR Parameter 'producttoken' contains an invalid value: '<producttoken>' Invalid or missing product token
200 Error: ERROR No sender name provided ‘from’ parameter is missing or its value was empty
200 Error: ERROR Parameter 'to' contains an invalid value: '<msisdn>' The value for the ‘to’ parameter is not a valid Phone Number
200 Error: ERROR Parameter 'body' is required The value for the ‘body’ parameter is missing

Glossary

Term Description
MT Mobile Terminated – term for a text message that is sent from your application to a handset.
MO Mobile Originated – term for a text message that is sent from a handset to your application.
SMPP Short Message Peer-to-Peer - standard telecom industry protocol for transferring short message data.
MSISDN Mobile Station International Subscriber Directory Number -
RCS Rich Communication Services - A telco level alternative to SMS featuring rich content chat options
WABA WhatsApp Business Account - A WhatsApp verified account for businesses

Conversion API

Adding conversion details for each message helps you to keep insight into conversions using Analytics and it helps CM to improve the quality of our service. We recommended looking into using the Conversion web API.

A conversion is a confirmation that an end-user has used the contents of the sms/voice/push message that was processed by CM.

If you wish to get started with the Conversion API, click here.