MoPub OpenRTB 2.3 and Native 1.0 Integration Guide

Deprecation Notice: MoPub has deprecated OpenRTB 2.3. Please refer to OpenRTB 2.5 instead.

Periodically review the changelog at the bottom of this page for updates!

This document serves as an integration guide and FAQ for our OpenRTB 2.3 + Native ads integration. If there is a conflict between this integration guide and your existing agreements with MoPub and Twitter, your agreements supersede this guide document.

1. Basic Auction on the MoPub Exchange

  1. MoPub receives an ad request from a mobile device.
  2. MoPub makes an HTTP POST request to all partner bidder HTTP endpoints. Each bidder must respond within the number of milliseconds passed in the bidrequest.tmax field.
  3. MoPub runs a first-price auction based on all the valid responses from the bidders.
  4. MoPub pings the winning bidder’s nurl(s) to notify the DSP of a win.
  5. MoPub sends down the winning bid’s HTML and imptrackers to the client.
  6. The mobile device pings the imptrackers URL(s) after the ad markup is rendered.

Refer to section 2.4 for more information on nurls and impression tracking

Important: All fields in the bid request are populated if available. MoPub never passes null values or empty strings. If a parameter is noted as not always being passed, that parameter may not be present in the bid request. For example, if the request doesn’t contain an SDK version, we will omit that parameter from the request.

It’s possible for an attribute to be marked as “not always passed” even when there is a very low probability of its absence; for example, country is passed >99% of the time.

2. Important Integration Notes

We strongly recommended that you read this section in full before you begin integration testing.

2.1 Key Changes from RTB 2.1

The following list enumerates the full set of changes from the MoPub 2.1 spec to MoPub 2.3. There are four categories. This is meant to be a checklist for integrations. Refer to the following tables and to the OpenRTB 2.3 spec for further descriptions on the fields.

  • [New]
  • [Updated]
  • [Moved]
  • [Removed]

RTB Request

  • wseat - [Removed]
  • regs - [New]
  • regs.coppa - [New]
  • regs.ext.gdpr - [New]
  • ext.pchain - [New]
  • imp.native - [New]
  • imp.secure - [New]
  • imp.pmp - [New] - note that this is new from the original 2.1 spec, but was implemented prior to 2.3 update
  • imp.ext.dlp - [New]
  • imp.ext.brsrclk - [New]
  • imp.banner.ext.nativebrowserclick - [Removed]
  • imp.banner.ext.video - [Removed]
  • imp.banner.ext.native - [Removed]
  • imp.banner.ext.nativead - [Removed]
  • imp.video.protocol - [Removed]
  • imp.video.companiontype - [New]
  • device.devicetype - [Updated]
  • device.lmt - [New]
  • device.dpidmd5 - [Updated] - deprecating
  • device.dpidsha1 - [Updated] - deprecating
  • device.h - [New]
  • device.w - [New]
  • device.model - [Updated]
  • device.hwv - [New]
  • device.ifa - [Moved]
  • device.geo.region - [Updated]
  • user.ext.consent - [New]

RTB Response

  • nbr - [New]
  • seatbid.bid.nurl - [Updated]
  • seatbid.bid.bundle - [New]
  • seatbid.bid.cat - [New]
  • seatbid.bid.h - [New]
  • seatbid.bid.w - [New]
  • seatbid.bid.dealid - [New] note that this is new from the original 2.1 spec, but was implemented prior to 2.3 update
  • seatbid.bid.ext.nurls - [New] (nurl array)
  • seatbid.bid.ext.imptrackers - [New]
  • seatbid.bid.ext.crtype - [Moved]
  • seatbid.bid.ext.native - [Removed]
  • seatbid.bid.ext.video - [Removed]
  • seatbid.bid.ext.duration - [Moved]
  • seatbid.bid.ext.video.type - [Removed]
  • seatbid.bid.ext.video.linearity - [Removed]

2.2 Note About OpenRTB 2.2 Bidders

Any OpenRTB 2.2-compliant bidder should have no problems integrating the MoPub 2.3 specification. The following lists a few important nuances to note for anyone on 2.2:

  1. bidrequest.device.lmt is new in 2.3 - ensure that you still ingest the dnt flag properly because it is always set when lmt=1.

  2. OpenRTB native support is only in v2.3 - you must upgrade to 2.3 to continue bidding on native ads.

  3. bidresponse.seatbid.bid.bundle is preferred when bidding with app advertisers; it is understood that this is not present on 2.2 bidders.

  4. bidresponse.seatbid.bid.cat - required for the advertiser category checking.

2.3 Notes About DNT, COPPA and Behavioral Targeting

  • Previously we set dnt=1 as a global identifier for ‘do not track’, signaling to the bidder to not behaviorally target a user per OBA guidelines.

  • With the fields introduced in OpenRTB 2.2 and 2.3, MoPub’s request signals the following:

    • dnt = 1 is always set as before, to ensure all bidders comply
    • lmt = 1 is set when the mobile limit ad tracking is set on an Android or iOS device
    • bidrequest.regs.coppa = 1 is set when the user is known to be a child under the age of 13, or the app is a child-directed application

2.4 nurl and Impression Tracking Updates

MoPub is making some important changes in the RTB 2.3 implementation to more closely align to the OpenRTB standard and introduce new ways for bidders to consistently track impressions for themselves and third parties. As of this release, the following are available:

  • bidresponse.seatbid.bid.nurl - this is an optional variable to notify a bidder when they won the auction. This does not guarantee that an impression is served, nor does MoPub charge when this tracker is sent. (The previous behavior for nurl was charging on this tracker and sending nurl client-side. nurl is now sent server-side.)

  • bidresponse.seatbid.bid.ext.nurls[] - this new optional extension field allows a bidder to submit multiple nurl trackers to optionally notify 3rd parties of the win. Note that nurl is sent server-side, and that if both nurl and the array are provided, we only use what the array field.

  • bidresponse.seatbid.bid.ext.imptrackers[] - this new extension field allows a bidder to submit one or more impression trackers that are sent on the impression or charge event for the ad. This is required in the RTB 2.3 bid response. Leveraging this field helps bidder (and third parties) minimize discrepancies with MoPub’s invoices. The logic for sending trackers in this field is identical to how MoPub previously sent nurl trackers in RTB 2.1. This does not apply for native. Bidders must use the native.imptrackers array to submit impression trackers instead.

2.5 Multiple Bid Responses and Multiple Seat Bids

DSPs are encouraged to send multiple bids for each seat represented in the bid response. These are collected in the bid array in the seatbid object. We consider all bids from all seats, exclude the ones that do not match blocklist or are invalid, and take the highest of the remaining eligible bids across each seat.

bidresponse.seatbid.seat technical requirements:

  • Alphanumeric (azAZ09)
  • Maximum length of 40 characters
  • Ideal minimum of 8 characters

Note that we currently support only one impression per auction, so these bids would all be competing for that single impression.

2.6.1 Native Browser Clicks

Partners may choose to use the native browser click functionality supported by the MoPub SDK where the click URL is opened in the device native browser instead of the in app webview.

You can target this functionality via the imp.ext.brsrclk field on the request (note that this is changed from imp.banner.ext.nativebrowserclick because it is supported for both video and native). If set to ‘1’, it is supported by the requesting SDK.

In the creative returned in the adm field, this behavior can be triggered by setting the click-through URL in the following format, using a custom URI pattern (this custom URI opens the URL in the native OS browser):

mopubnativebrowser://navigate?url=[URL_ENCODED_CLICKTHROUGH_URL]

Important: Ensure that http:// or https:// is included in the intended landing page URL.

For more information and examples, refer to our article on native browser clicks.

Starting in MoPub’s SDK version 3.9, we standardized an improved approach to submitting deep links that ensure a better end user experience + improved buy-side tracking. To leverage deep link plus do the following:

  1. Target the bid request flag imp.ext.dlp - if present, Deep Link+ is supported
  2. Submit all deep links with the deeplink+ scheme:
deeplink+://navigate?
            primaryUrl=PRIMARY_DEEPLINK&
            primaryTrackingUrl=PRIMARY_TRACKER&
            fallbackUrl=FALLBACK_URL&
            fallbackTrackingUrl=FALLBACK_TRACKER

Example deeplink+:

deeplink+://navigate?
            primaryUrl=twitter%3A%2F%2Ftimeline&
            primaryTrackingUrl=http%3A%2F%2Fmopub.com%2Fclicktracking&
            primaryTrackingUrl=http%3A%2F%2Fmopub.com%2Fmopubtracking&
            fallbackUrl=http%3A%2F%2Fmobile.twitter.com

2.7 OpenRTB Native Specification v1.0

This update includes support for the new Native Ads 1.0 sub specification for OpenRTB. We have a few important notes regarding this update for MoPub’s exchange:

  1. native.request is a string - Note that there is always a leading “native” object inside the request object to note a native creative request type.
  2. bidders have two options for returning ad markup

    • (preferred method) As a JSON object in the ext.admnative field (note that this is similar to MoPub’s original method of native ad bidding)

    • as a serialized string in the adm field (as noted by OpenRTB)

  3. MoPub is requiring a minimum width and height of 80x80px for the icon asset. A value of 80 is passed in the bid request assets.img.wmin and assets.img.hmin.
  4. Main image and icon image height and width are required in the bid response image object.
  5. Current bidders in MoPub’s native ads can map the data fields to the following asset object IDs:
    • 1 = title
    • 2 = main image
    • 3 = icon
    • 4 = text
    • 5 = ctatext
    • 6 = starrating
    • 7 = VAST

2.8 Notes About SSL

Currently, all MoPub in-app inventory supports both SSL and non-SSL creative. Bidders may choose how they want to deliver ad markup as a result of a winning bid.

Additionally, with respect to the bid request and response, we are currently investigating whether to require SSL here and will formally provide details once we’ve made an internal decision.

If you have any specific requirements or questions regarding SSL (creative or OpenRTB integration), please let your account team know.

2.9 Notes About VAST Support

  • All VAST videos auto-play on iOS and Android when video is enabled
  • Linear videos only

2.9.1 Bid Request

To verify if an ad impression can accept a video ad, the DSP must check for the following:

  • Auto-play video is not one of the blocked attributes in the banner object (from the battr field).
  • The value is derived from Section 5.3 of RTB 2.3 spec. For auto-play video ads, its value is 6. Thus, if battr doesn’t contain 6 in the array, you can target auto-play video.

2.9.2 Bid Response

Note that VAST videos and opt-in rewarded ad bid responses should be identical and follow the requirements below. Refer to the video bid response (section 6.2.3) for both video and rewarded ad bid response examples.

Required fields:

  • bid.ext.duration
    • Must match the actual length of the video
    • Must adhere to min/max duration passed in the bid request
  • bid.ext.crtype
    • Type of video being served
  • bid.attr
    • This field indicates the type of creative being served
    • Its value is derived from Section 5.3 of RTB 2.3 spec
    • For auto-play video ads, its value is 6
  • bid.adm
    • The adm (or admarkup field) contains the entire VAST 2.0 XML payload, VAST 2.0 Wrapper, VAST 3.0 XML payload, or VAST 3.0 Wrapper
    • URL-encoded VAST tags are NOT supported

2.10 Inventory Packages

Inventory packages will follow similar specifications to PMPs. Refer to the pmp object (Section 3.2.17) and Auction Types (Section 7) for more information.

Bid Response

Look for a matching campaign for the requested Inventory Package. If there is a matching campaign found, return the dealID in the bid response. If there is no campaign for that inventory package, fallback to the open auction and do not respond with a dealID. Contact your account manager to be enabled for Inventory Packages.

2.11 Viewability Support

This section contains legacy information. Starting from MoPub 5.13.0, the Moat and IAS viewability SDKs have been removed. Viewability tracking logic is no longer operational via these proprietary SDKs.

DSPs can transact against inventory that has a viewability enabled SDK through Inventory Packages or the Viewability Vendor Flag

Inventory Packages

DSPs can transact against IAS and/or Moat inventory packages today. Viewability inventory packages represent publisher app inventory that currently have the IAS and/or Moat SDK integrated. To get started, contact your account team. Refer to the preceding section to learn more.

Viewability Vendor Flag

This section contains legacy information. Starting from MoPub 5.13.0, the Moat and IAS viewability SDKs have been removed. Viewability tracking logic is no longer operational via these proprietary SDKs.

We are adding support for DSPs to target inventory that has the IAS and/or Moat SDK integrated. By delivering an IAS or Moat tag to an SDK that supports viewability, buyers can get more robust and accurate measurement.

Bid Request: The bid request will contain imp.ext.metric object, which sends the vendor SDK that the publisher supports (refer to sections 3.2.2.1 and 3.2.2.1.1).

Bid Response: Buyers are required to respond with the vendor in the bid response bid.ext when they are returning a campaign for viewability (refer to section 4.2.4).

We encourage you to read through our Viewability FAQ.

2.12 GDPR

For more information about GDPR, refer to our FAQ.

bidrequest.regs.ext.gdpr

The regs object signals whether or not the request is subject to GDPR regulations. It does so via the extension attribute gdpr, which is an integer that indicates: ‘0’ = No, ‘1’ = Yes. The extension is an object.

bidrequest.user.ext.consent

The user object conveys user consent when GDPR regulations are in effect. It does so via the extension attribute consent. This string passes ‘1’, indicating the user has provided consent; or ‘0’, indicating that the user has not consented. The extension is an object, and if GDPR does not apply, this field is omitted from the bid request.

If we do not have consent, we do not collect the following fields. Additionally, all of these fields except IFA will be omitted from the request. IFA will be present; however, it will contain zeros.

  • advertising ID
  • latitude and longitude
  • age
  • gender
  • interest and demographic keywords
  • IP address: we truncate the 8 lowest bits
  • city
  • metro
  • region
  • zipcode

Refer to our Sample GDPR Consent/No Consent Requests.

3. Bid Request Variables and Definitions

Ensure you have the OpenRTB 2.3 Specification Guide available while consulting the following material. This document contains information and nuances specific to MoPub’s implementation and we expect that you also follow the guidelines presented in OpenRTB when unchanged.

Additional notes:

  • The following section naming follows OpenRTB for simplicity.
  • All fields in the bid request are populated if available. MoPub never passes null values or empty strings. If a parameter is noted as not always being passed, that parameter may not be present in the bid request. For example, if the request doesn’t contain an SDK version, we will omit that parameter from the request.
  • Types and descriptions from OpenRTB are not included below.
  • Any objects and attributes from OpenRTB not supported by MoPub are noted by strikethrough font.
Object Section Description
bidrequest 3.2.1 Top-level object.
imp 3.2.2 Container for the description of a specific impression; at least 1 per request.
banner 3.2.3 Details for a banner impression (incl. in-banner video) or video companion ad.
video 3.2.4 Details for a video impression or the video asset of a native impression.
native 3.2.5 Container for a native impression conforming to the Native Ad Spec.
site 3.2.6 Details of the website calling for the impression.
app 3.2.7 Details of the application calling for the impression.
publisher 3.2.8 Entity that controls the content of and distributes the site or app.
content 3.2.9 Details about the published content itself, within which the ad will be shown.
producer 3.2.10 Producer of the content; not necessarily the publisher (e.g., syndication).
device 3.2.11 Details of the device on which the content and impressions are displayed.
geo 3.2.12 Location of the device or user's home base depending on the parent object.
user 3.2.13 Human user of the device; audience for advertising.
data 3.2.14 Collection of additional user targeting data from a specific data source.
segment 3.2.15 Specific data point about a user from a specific data source.
regs 3.2.16 Regulatory conditions in effect for all impressions in this bid request.
pmp 3.2.17 Collection of private marketplace (PMP) deals applicable to this impression.
deal 3.2.18 Deal terms pertaining to this impression between a seller and buyer.

3.2.1 Object: bidrequest

Attribute Always Passed MoPub implementation specifics
id Yes Unique ID of the bid request, provided by the exchange. (this is the field that is mapped to "id" in bid response)
imp Yes Array of imp objects (section 3.2.2) representing the impressions offered. Only one impression object will be passed.
site No (either site or app always) Details via a site object (Section 3.2.6) about the publisher's website. Sent when the impression is mobile web.
app No (either site or app always) Details via an app object (Section 3.2.7) about the publisher's app (that is, non-browser applications). Sent for all mobile application requests.
device Yes Details via a device object (Section 3.2.11) about the user's device to which the impression will be delivered.
user No Details via a user object (Section 3.2.13) about the human user of the device; the advertising audience.
test n.a Indicator of test mode in which auctions are not billable, where '0' = live mode, '1' = test mode.
at Yes Always set to '1' for MoPub, meaning 1st price auction.
tmax yes Maximum time in milliseconds to submit a bid to avoid timeout. The default value passed is typically 300 or 410 ms for Marketplace line items and 1000ms for the Unified Auction. For partners connected to our APAC POP, the default value is typically 180 ms.
wseat n.a Allowlist of buyer seats allowed to bid on this impression. Seat IDs must be communicated between bidders and the exchange a priori. Omission implies no seat restrictions.
allimps n.a Flag to indicate if Exchange can verify that the impressions offered represent all of the impressions available in context (e.g., all on the web page, all video spots such as pre/mid/post roll) to support road-blocking. 0 = no or unknown, 1 = yes, the impressions offered represent all that are available.
cur n.a Array of allowed currencies for bids on this bid request using ISO-4217 alpha codes. Recommended only if the exchange accepts multiple currencies.
bcat No Blocked advertiser categories using the IAB content categories. Refer to List 5.1.
badv No Block list of advertisers by their top-level domains (e.g., "ford.com").
regs No A `regs` object (section 3.2.16) that specifies any industry, legal, or governmental regulations in force for this request.
ext Yes Placeholder for exchange-specific extensions to OpenRTB.

3.2.2 Object: imp

Attribute Always Passed Description
id yes A unique identifier for this impression within the context of the bid request . Set to 1, indicating that this is the first (and only) impression in the bid request. (Map this value to bid.impid in the response)
banner only for banner imps A `banner` object (section 3.2.3); required if this impression is offered as a banner ad opportunity.
video only for video imps A `video` object (section 3.2.4); required if this impression is offered as a video ad opportunity.
native only for native imps A `native` object (section 3.2.5); required if this impression is offered as a native ad opportunity.
displaymanager no Will pass "mopub" when the SDK is present.
displaymanagerver no MoPub SDK version passed from the SDK, otherwise not passed
instl yes 1 = the ad is interstitial or full screen, 0 = not interstitial.
tagid yes Identifier for specific ad placement or ad tag that was used to initiate the auction. This can be useful for debugging of any issues, or for optimization by the buyer. This is known as "adunit id" by MoPub publishers.
bidfloor yes Minimum bid for this impression expressed in CPM.
bidfloorcur
n/a Currency specified using ISO-4217 alpha codes. This may be different from bid currency returned by bidder if this is allowed by the exchange.
secure yes Flag to indicate if the impression requires secure HTTPS URL creative assets and markup, where 0 = non-secure, 1 = secure. If omitted, the secure state is unknown, but non-secure HTTP support can be assumed.
iframebuster n/a Array of exchange-specific names of supported iframe busters.
pmp no A `pmp` object (section 3.2.17) containing any private marketplace deals in effect for this impression.
ext n/a Placeholder for exchange-specific extensions to OpenRTB.

3.2.2.1 Object: imp.ext

Attribute Always Passed Description
brsrclk no Set to 1 if Native Browser Clicks are supported.
dlp no Set to 1 if Deep Link+ is supported (SDK 3.9+)
metric no Array of metrics supported by the impression
skadn no Support for Apple's SKAdNetwork

3.2.2.1.1 Object: imp.ext.metric

Object Array: If the inventory supports viewability, the metric object will be present in the bid request.

Attribute Type Description
type string Type of metric being presented using exchange curated string names which should be published to bidders a priori.
Set to viewability
vendor string Source of the value using exchange curated string names which should be published to bidders a priori.
Set to “ias” for Integral Ad Science (IAS) Set to “moat” for Moat Dependent on the partners that are supported by the publisher. If only one is supported, only one will be passed. If both are supported, both will be passed
3.2.2.1.2 Object: imp.ext.skadn

Please refer to the OpenRTB SKAdNetwork extension for additional details.

Attribute Always Passed Description
version yes Version of SKAdNetwork supported. Always "2.0" or higher. Dependent on both the OS version and the SDK version.

Note: With the release of SKAdNetwork 2.1, this field is deprecated in favor of the BidRequest.imp.ext.skadn.versions to support an array of version numbers.
versions yes Array of strings containing the supported skadnetwork versions. Always "2.0" or higher. Dependent on both the OS version and the SDK version.
sourceapp yes ID of publisher app in Apple’s App Store. Matches app.bundle
skadnetids yes A subset of SKAdNetworkItem entries in the publisher app’s Info.plist that are relevant to the DSP.

3.2.3 Object: banner

Attribute Always Passed Description
w yes Width of the impression in pixels. This value is an exact width requirement.
h yes Height of the impression in pixels. This value is an exact height requirement.
wmax n/a Maximum width of the impression in pixels. If included along with a w value then w should be interpreted as a recommended or preferred width.
hmax n/a Maximum height of the impression in pixels. If included along with an h value then h should be interpreted as a recommended or preferred height.
wmin n/a Minimum width of the impression in pixels. If included along with a w value then w should be interpreted as a recommended or preferred width.
hmin n/a Minimum height of the impression in pixels. If included along with an h value then h should be interpreted as a recommended or preferred height.
id n/a Unique identifier for this `banner` object. Recommended when `banner` objects are used with a `video` object (section 3.2.4) to represent an array of companion ads. Values usually start at 1 and increase with each object; should be unique within an impression.
btype yes Blocked banner ad types. Refer to List 5.2. Set to [4], to reflect our platform-wide prohibition on IFRAMEs
battr yes Blocked creative attributes. Refer to List 5.3. Refer to MoPub's demand side policies for detailed requirements.
pos yes Ad position on screen. Refer to List 5.4. Position is set to 1 ("above the fold", i.e. visible)
mimes n/a Content MIME types supported. Popular MIME types may include application/x-shockwave-flash, image/jpg, and image/gif.
topframe n/a Indicates if the banner is in the top frame as opposed to an iframe, where 0 = no, 1 = yes.
expdir n/a Directions in which the banner may expand. Refer to List 5.5.
api no List of supported API frameworks for this impression. Refer to List 5.6. If an API is not explicitly listed, it is assumed not to be supported.
ext no Placeholder for exchange-specific extensions to OpenRTB.

3.2.3.1 Object: banner.ext

Attribute Always Passed Description
format no Array of `format` objects representing the banner sizes permitted. If none are specified, then use of the `h` and `w` attributes is highly recommended.

3.2.3.1.1 Object: banner.ext.format

Attribute Type Description
w integer Width in device independent pixels (DIPS).
h integer Height in device independent pixels (DIPS).

3.2.4 Object: video

Attribute Always Passed Description
mimes yes Content MIME types supported. Flash is not supported. MoPub supported MIMEs are: iOS: [video/3gpp, video/3gpp2, video/mp4, video/quicktime, video/x-m4v] Android: [video/mp4, video/.3gp]
minduration yes Minimum video ad duration in seconds.
maxduration yes Maximum video ad duration in seconds.
protocol n/a Use of protocols instead is highly recommended. Supported video bid response protocol. Refer to List 5.8. At least one supported protocol must be specified in either the protocol or protocols attribute.
protocols yes Array of supported video bid response protocols. Refer to List 5.8. We support VAST 2.0, 3.0 and wrappers. Protocols will reflect what the specific inventory source supports as some inventory only supports 2.0, others both 2.0/3.0.
w yes Width of the video player in pixels.
h yes Height of the video player in pixels.
startdelay yes Indicates the start delay in seconds for pre-roll, mid-roll, or post-roll ad placements. Refer to List 5.10 for additional generic values. MoPub always passes 0.
linearity yes Indicates if the impression must be linear, nonlinear, etc. We only support linear video, i.e., linearity = 1
sequence n/a If multiple ad impressions are offered in the same bid request, the sequence number will allow for the coordinated delivery of multiple creatives.
battr yes Blocked creative attributes. Refer to List 5.3. Refer to MoPub's demand side policies for detailed requirements.
maxextended n/a Maximum extended video ad duration if extension is allowed. If blank or 0, extension is not allowed. If -1, extension is allowed, and there is no time limit imposed. If greater than 0, then the value represents the number of seconds of extended play supported beyond the maxduration value.
minbitrate n/a Minimum bit rate in Kbps. Exchange may set this dynamically or universally across their set of publishers.
maxbitrate n/a Maximum bit rate in Kbps. Exchange may set this dynamically or universally across their set of publishers.
boxingallowed n/a Indicates if letter-boxing of 4:3 content into a 16:9 window is allowed, where 0 = no, 1 = yes.
playbackmethod yes Allowed playback methods. If none specified, assume all are allowed. Refer to List 5.9
delivery n/a Supported delivery methods (e.g., streaming, progressive). If none specified, assume all are supported. Refer to List 5.13
pos n/a Ad position on screen. Refer to List 5.4
companionad n/a Array of `banner` objects (section 3.2.3) if companion ads are available.
api n/a List of supported API frameworks for this impression. Refer to List 5.6. If an API is not explicitly listed, it is assumed not to be supported.
companiontype yes Supported VAST companion ad types. Refer to List 5.12. Some inventory supports all companion types and others static only. Target the correct companion types 1,2,3.
ext no Passed for opt-in rewarded ad requests only.

3.2.4.1 Object: video.ext

Attribute Always Passed Description
skip yes Indicates if the player will allow the video to be skipped, where 0 = no, 1 = yes MoPub always sets to 0 to identify non-skip opt-in rewarded ad Currently passed for opt-in rewarded ad requests only.
videotype yes Always set to "rewarded" indicating the request is for an opt-in rewarded ad.

3.2.5 Object: native

Attribute Always Passed Description
request yes Request payload complying with the Native Ad Specification. Note that this is a string.
ver yes Version of the Native Ad Specification to which request complies; highly recommended for efficient parsing.
api n/a List of supported API frameworks for this impression. Refer to List 5.6. If an API is not explicitly listed, it is assumed not to be supported.
battr yes Blocked creative attributes. Refer to List 5.3. Refer to MoPub's demand side policies for detailed requirements.
ext n/a Placeholder for exchange-specific extensions to OpenRTB.

3.2.6 Object: site

Attribute Always Passed Description
id yes Exchange-specific site ID.
name yes The Site name as entered by the publisher in MoPub UI (may be aliased at the publisher's request).
domain yes Domain of the site (e.g., "mysite.foo.com").
cat yes Array of IAB content categories of the site. Refer to List 5.1. These are self declared by publisher.
sectioncat n/a Array of IAB content categories that describe the current section of the site. Refer to List 5.1.
pagecat n/a Array of IAB content categories that describe the current page or view of the site. Refer to List 5.1.
page n/a URL of the page where the impression will be shown.
ref n/a Referrer URL that caused navigation to the current page.
search n/a Search string that caused navigation to the current page.
mobile n/a Mobile-optimized signal, where 0 = no, 1 = yes.
privacypolicy n/a Indicates if the site has a privacy policy, where 0 = no, 1 = yes.
publisher yes Details about the Publisher (Section 3.2.8) of the site.
content n/a Details about the Content (Section 3.2.9) within the site.
keywords n/a Comma separated list of keywords about the site.
ext n/a Placeholder for exchange-specific extensions to OpenRTB.

3.2.7 Object: app

Attribute Always Passed Description
id yes Exchange-specific app ID.
name yes App name (may be aliased at the publisher's request).
bundle no Application bundle or package name (e.g., com.foo.mygame); intended to be a unique ID across exchanges. iOS will pass the app store ID, Android the package bundle. Not passed for blind apps This is currently self-declared by applications.
domain n/a Domain of the app (e.g., "mygame.foo.com").
storeurl no App store URL for an installed app; for QAG 1.5 and `app-ads.txt` compliance. Example: https://itunes.apple.com/us/app/twitter/id333903271 & https://play.google.com/store/apps/details?id=com.twitter.android - based on publisher inputs.
cat yes Array of IAB content categories of the app. Refer to List 5.1. These are self declared by publisher.
sectioncat n/a Array of IAB content categories that describe the current section of the app. Refer to List 5.1.
pagecat n/a Array of IAB content categories that describe the current page or view of the app. Refer to List 5.1.
ver no Application version. passed when available
privacypolicy n/a Indicates if the app has a privacy policy, where 0 = no, 1 = yes.
paid n/a 0 = app is free, 1 = the app is a paid version.
publisher yes Details about the Publisher (Section 3.2.8) of the app.
content n/a Details about the Content (Section 3.2.9) within the app.
keywords n/a Comma separated list of keywords about the app.
ext n/a Placeholder for exchange-specific extensions to OpenRTB.

3.2.8 Object: publisher

Attribute Always Passed Description
id yes Exchange-specific publisher ID.
name yes Publisher name (may be aliased at the publisher's request).
cat n/a Array of IAB content categories that describe the publisher. Refer to List 5.1.
domain n/a Highest level domain of the publisher (e.g., "publisher.com").
ext n/a Placeholder for exchange-specific extensions to OpenRTB.

3.2.11 Object: device

Attribute Always Passed Description
ua usually Browser user agent string.
geo yes Location of the device assumed to be the user's current location defined by a `geo` object (Section 3.2.12).
dnt no Standard "Do Not Track" flag as set in the header by the browser, where 0 = tracking is unrestricted, 1 = do not track. Only passed when DNT=1. Note that this field is the catch all for signaling not to behaviorally target. We will pass this for any browser dnt signal, lmt signal or coppa flagged user.
lmt no "Limit Ad Tracking" signal commercially endorsed (e.g., iOS, Android), where 0 = tracking is unrestricted, 1 = tracking must be limited per commercial guidelines.
ip yes IPv4 address closest to device.
ipv6 n/a IP address closest to device as IPv6.
devicetype no The general type of device. Refer to List 5.17. Types 4 = phone, 5 = tablet are only available on iOS
make no Device make (e.g., “Apple”).
model no Device model (e.g., “iPhone”). iOS will show iPhone, iPad, iPod Android will have detailed model information such as “SAMSUNG-SM-G900A”
os no Device operating system (e.g., “iOS” or “Android”).
osv no Device operating system version (e.g., “3.1.2”).
hwv no Hardware version