OMID chapter navigation

OpenRTB / AdCOM carriage

carriage

Source status：The only official source on the OpenRTB side is the Working Draft of July 2018, which predates the final OpenRTB 2.6. Its statements about 2.6 and AdCOM 1.0 reflect the draft as it stood then; where they differ from this site's OpenRTB 2.6 field baseline, the OpenRTB module's official 2.6 text prevails, and this page covers only the OMID-related ext conventions.

On this page

Role & scope
API Frameworks list (List 5.6)
Request side: whether the placement supports OMID
Response side: whether the creative requires OMID
Partner identity: omidpn and omidpv
Where omidpn / omidpv are attached
Event tracker carriage for Native ads
Related chapters

Role & scope

The capability declaration and partner identity of the Open Measurement Interface Definition (OMID) are carried through the auction by OpenRTB and AdCOM. Request side: imp.{banner,video,audio,native}.api with value 7 (OMID-1 in the AdCOM APIFrameworks list) declares that the placement supports OMID, bid.apis declares that the creative requires OMID, and source.ext.omidpn / source.ext.omidpv carry the name and versionString of the OMID Partner object. For Native ads a custom event tracker with event value 555 carries the verification script resource.

Format: OpenRTB 2.0–2.6 · AdCOM 1.0
Source status: Working Draft · 2018-07
Carriage point: api = 7 · omidpn · omidpv · event 555
Official docs: CC-BY 3.0 (IAB Tech Lab) ↗

API Frameworks list (List 5.6)

Literal value	Official description
1	VPAID 1.0
2	VPAID 2.0
3	MRAID-1
4	ORMMA
5	MRAID-2
6	MRAID-3
7	OMID-1

The advisory proposes extending OpenRTB's API Frameworks list as above, with value 7 meaning OMID 1.0. Value 6 does not exist in OpenRTB 2.0 and 2.1; when extending an existing 2.0 / 2.1 implementation the advisory suggests skipping 6 and using 7 for OMID support to preserve an upgrade path. The same list for OpenRTB 2.6 on this site is in the AdCOM enumeration overview (list_apiframeworks), where value 7 is officially described as 'OMID 1.0'.

Request side: whether the placement supports OMID

The request side uses the api field to declare which API frameworks this placement supports. The advisory's wording is that an API not explicitly listed is assumed not to be supported.

Carriage point	Type	Since	Meaning
imp.{banner,video,audio,native}.api	integer array	OpenRTB 2.0+	Including value 7 declares OMID support for the placement. The advisory's table is headed Banner/Video/Native/Audio Object, i.e. all four impression-format objects use this field.ENList 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.

Response side: whether the creative requires OMID

The response side uses fields on the Bid object to declare that the returned creative requires OMID. This differs from the request side, which states placement capability rather than creative requirement.

Carriage point	Type	Since	Meaning
bid.apis	integer array	OpenRTB 2.6	The array form introduced in 2.6; the AdCOM field of the same name is apis.ENA list of APIs required by the markup if applicable. Refer to List 5.6.
bid.apideprecated	integer	OpenRTB 2.4+	The single-value form, superseded by the apis array in 2.6; still encountered in legacy 2.4 / 2.5 responses.ENNOTE: Deprecated in favor of the apis integer array in OpenRTB 2.6. API required by the markup if applicable. Refer to List 5.6.

Partner identity: omidpn and omidpv

These two fields identify which integration (ad SDK) has OM SDK installed, and they are separate from the API frameworks array: the array declares capability while these declare the implementer. Both correspond to constructor parameters of the OMID Partner object.

Carriage point	Type	Since	Meaning
omidpn	string	—	Corresponds to the Partner object's name parameter; on the VAST side it is carried by the first half of the [OMIDPARTNER] macro.ENIdentifier of the OM SDK integration. This is the same as the "name" parameter of the OMID Partner object.
omidpv	string	—	Corresponds to the Partner object's versionString parameter; on the VAST side it is carried by the second half of the [OMIDPARTNER] macro.ENVersion of the OM SDK integration. This is the same as the "versionString" parameter of the OMID Partner object.

Where omidpn / omidpv are attached

OpenRTB 2.xBidRequest.Source.Ext

The advisory lists three possible extension locations and states that Source.Ext is appropriate when the certification applies to all placements in the bid request.

"source": {
  "ext": {
    "omidpn": "MyIntegrationPartner",
    "omidpv": "7.1"
  }
},
"imp": [{
  "banner": { "api": [7] }
}]

OpenRTB 3.0 / AdCOM 1.0events.ext

AdCOM expresses a bid request's OMID capability in the events object, so the advisory considers it logical to carry the partner information in the same object; the capability itself travels in events.apis.

"events": {
  "apis": [7],
  "ext": {
    "omidpn": "MyIntegrationPartner",
    "omidpv": "7.1"
  }
}

The two fields have the same names and types in OpenRTB 2.x and 3.0; only the object they hang off differs. In the official proto's Source.Ext, omidpn and omidpv are fields 2 and 3 respectively.

Event tracker carriage for Native ads

OpenRTB Native Ads 1.2 §4.7 Event Trackers Request Object

Native ads do not deliver verification scripts through an impression-format object's api field; they reuse event trackers, with a custom event value marking the resource as OMID and the SSP and publisher deciding when to execute the script.

Object	Literal value	Meaning
event	555	OMID — new custom valueENEvent should be set to a custom value of "555" to signify that this is OMID and the SSP and publisher will determine when to execute OMID script.
method	2	JS (existing value of 2)ENMethod should always be "2" for JS. Previous guidance to use '555' is not necessary unless the script is non-JS, non-img.
ext.vendorKey	ext	The vendor key of the company providing the OMID JavaScript; the same role as Verification@vendor on the VAST side. SSPs / publishers must pass it to OMID when provided.ENThe vendor key for the company providing the OMID javascript, e.g. "company.com-omid"
ext.verification_parameters	ext	Additional verification parameters for OM SDK; the same role as VerificationParameters on the VAST side. The official text carries a punctuation defect here (e.g,.) which this site reproduces as-is.ENAdditional verification parameters for the OMSDK, populated by e.g,. "[parameters string]"

"eventtrackers": {
  "event": 555,
  "method": 2,
  "url": "https://verification.com/omid_verification.js",
  "ext": {
    "vendorKey": "company.com-omid",
    "verification_parameters": "[parameters string]"
  }
}

The verification script URL goes in the standard eventtrackers.url field; no new field is invented.
The two ext extensions are custom fields any exchange can support, but the advisory strongly recommends that SSPs and DSPs support them as part of their OMID support.