Content Types

Infobip API supports several content types. Most API requests and responses will be either application/json or application/xml. Take a minute to find out more about the JSON format and XML format. 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.

Specify 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. 

Request example:

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

Response example:

    "results": []

Path Extension

If for any reason you are unable to modify the Accept header of your API call, there is another way to request 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

The following 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'?>

Specify 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.


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 an SMS message in either JSON or XML, but you have 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

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, and here are some common ones:

  • The 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 dedicated documentation of the targeted API endpoint and the list of accepted parameters defined there.

Response Parsing

When parsing the API responses, make sure to adhere to 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. Therefore, 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.