Content types

Read about the various content types Infobip API supports.

Infobip API supports several content types. Most of the API requests and responses will be either application/json or application/xml. You can find out more about json format here, and xml here. Note that some API endpoints, like email sending, use multipart/form-data so it is advisable to check the dedicated documentation page of your targeted endpoint for details.

Specifying response content type

You can specify the desired API response content type in one of two ways.

Accept header

The first one is by using the standard Accept HTTP header. For example, this request:

GET /sms/1/reports HTTP/1.1
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Accept: application/json

will produce a json formatted response that might look like this:

    "results": []

Path extension

If for any reason you are unable to modify the Accept header of your API call then there is a second way of requesting a specific content type. To do so, append the request path with the extension corresponding to the content type of your choosing.

content type path extension
application/json .json
application/xml .xml

For example, the request:

GET /sms/1/reports.xml HTTP/1.1
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

will result in a response with the xml format that could look something like this:

<?xml version='1.0' encoding='UTF-8'?>

Specifying request content type

The content type of your request body data should be specified in the Content-Type header of the request. If not otherwise specified, API endpoints will accept either application/json or application/xml types of content.

Important Note

It is mandatory to specify the Content-Type header for API requests that contain HTTP message body data. Those are typically requests using the POST and PUT HTTP methods.

For example, you can format the SMS message in either json or xml, but are required to fill out the Content-Type header accordingly:

POST /sms/1/text/single HTTP/1.1
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Content-Type: application/json

   "text":"Test SMS."
POST /sms/1/text/single HTTP/1.1
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Content-Type: application/xml

   <text>Test SMS.</text>

Lastly, note that the API response will match the submitted content by default. However, you can modify this behavior by explicitly setting the Accept header if you wish to receive the API response in the content type different from the one used to submit request body data. This is useful when sending an e-mail in multipart/form-data format so another content type for the response is desirable:

POST /email/1/send HTTP/1.1
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Accept: application/json
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW

Content-Disposition: form-data; name="from"

Jane Doe <>
Content-Disposition: form-data; name="to"
Content-Disposition: form-data; name="subject"

Mail subject text
Content-Disposition: form-data; name="text"

Mail body text

The above request will produce a response in json format.

Bad request errors requests

API will try to distinguish between common mistakes and respond in an appropriate way. For example, if there is something wrong with the HTTP message body data API will respond with the HTTP status 400 (Bad request) and the response body might look like this:

    "requestError": {
        "serviceException": {
            "messageId": "BAD_REQUEST",
            "text": "Bad request"
<?xml version='1.0' encoding='UTF-8'?>
            <text>Bad request</text>

This response can have several causes, here are a few of the common ones:

  • Content-Type header is missing
  • Content-Type does not match the submitted body data
  • Submitted body data does not respect the json or xml format

However, unrecognized parameters in API request body data will be ignored without the request automatically failing, as long as the request is properly formatted. Because of this, it is recommended to consult with the dedicated documentation of the targeted API endpoint and the list of accepted parameters defined there.

Response parsing

When parsing the API responses take care to respect the json or the xml specifications. There are specific details associated with each one, for example, json format does not guarantee the order of name/value pairs in objects. Thus you should never depend on the order of properties when parsing json API responses.

Depending on your language of choice there is either native support for json / xml parsing built in or you might use some external library that handles it.