Getting Started

Version

The InMobi RTB platform follows the standards set by OpenRTB Version 2.5. OpenRTB version is communicated via header: x-openrtb-version: 2.5.

Transport

The base protocol for communication is HTTP. Specifically, HTTP POST is used for bid requests to accommodate greater payloads than HTTP GET and to facilitate the use of binary representations. HTTP GET is used for billing notifications.

Calls returning content (e.g., any bid response, a win notice that returns markup) should return HTTP code 200. Calls returning no content in response to valid requests (e.g., an empty bid response that indicates no bid, a win notice that does not return markup) should return HTTP 204. Invalid calls (e.g., a bid request containing a malformed or corrupt payload) should return HTTP 400 with no content.

Data Format

The format for bid request and bid response data payloads is JSON (JavaScript Object Notation). The bid request specifies using the Content-Type HTTP header with the standard mime type for JSON: application/JSON. Hence, the format for the bid response must be in JSON.

Data Encoding

Compressing the data sent between exchanges and bidders can be very beneficial. Compression hugely reduces the size of data transferred and thus, saves network bandwidth both for the exchanges and the bidders. Compression should be enabled both for the bid request sent by the exchange and the bid response returned by the bidder to realize these savings fully. The InMobi RTB platform sends compressed requests to bidders and expects compressed responses in return. 
  
Compression is enabled for bid requests/responses using standard HTTP 1.1 mechanisms. Most web servers already support gzip compression of response content. The InMobi RTB platform will always signal that they would like responses to be compressed, by setting the standard HTTP 1.1 Accept-Encoding header with the value "gzip": Accept-Encoding: gzip.

If the bidder server supports this and is correctly configured, it will automatically respond with gzip encoded content. This is indicated using the standard HTTP 1.1 Content-Encoding header: Content-Encoding: gzip. 

Compression is always enabled on the bid request. The exchange indicates a gzip-compressed bid request by setting the HTTP 1.1 Content-Encoding header with the value "gzip": Content-Encoding: gzip.

Important

• We have stopped supporting the below fields:
  • pmp.private_auction: It means InMobi does not support private auctions, and the Open RTB-defined default value of 0 can be assumed.
  • deal.bidfloorcur: It can be assumed to be equal to bidcur.
  • banner.mimes: It is removed from the request, but InMobi continues to support popular MIME types.
  • device.ext.idfa and md5/sha1: These variants are removed, and the requests now have device.ifa.
  • user.ext.ageId: It means InMobi will not pass the Age Enumeration ID.
  • app.ext.fs: It means InMobi will not pass the Family Safe or Performance App Rating.
• An ad impression that can support multiple ad formats will be sent as separate ad requests, each offering a single ad format opportunity to bidders.
• Ad Auditing and Quality Requirements: InMobi reviews the quality of ads served by bidders.
  • Ads that fail to comply with content guidelines and don’t adhere to the mandatory requirements shared below are invalidated and not allowed to compete in the auction.
  • Buyers must honor the ad and category blocks present in the request.
  • To ensure a higher ad auditing and quality standard, all buyers must send the following parameters in the bid response mandatorily.