OpenRTB protocol
OpenRTB enumerated lists reference
The integer codes an OpenRTB 2.6 bid request uses for auction type, device type, connection type, video placement, playback, API frameworks, creative attributes, protocols, position, and linearity, with the exact values from the AdCOM 1.0 lists the 2.6 spec references.
Where the lists live now
As of OpenRTB 2.6, the request-side enumerated lists are kept in the AdCOM 1.0 specification (no-bid and loss reason codes live in the OpenRTB 3.0 document) so they can change without a new OpenRTB release. Field tables in 2.6 say things like "Refer to List: Device Types in AdCOM 1.0". In OpenRTB 2.5 and earlier the same lists sat in section 5 of the spec itself, so older integration docs cite section numbers (5.21 Device Types, 5.9 Video Placement Types) for values that are now AdCOM lists. The values below reflect OpenRTB 2.6 with the current AdCOM lists, including the 2.6-202303 plcmt update. Where a list reserves 500 and above for exchange-specific or vendor-specific values, the table says so. See OpenRTB versions for what changed when.
Auction type (at)
BidRequest.at, integer, default 2. This one is defined in the OpenRTB spec itself, not AdCOM.
| Value | Name | Meaning |
|---|---|---|
1 | First Price | Winner pays what they bid. |
2 | Second Price Plus | Winner pays just above the second-highest bid; the spec default. |
500+ | Exchange-specific | Custom auction types agreed with buyers. |
Device type (device.devicetype)
AdCOM List: Device Types, derived from the TAG Inventory Quality Guidelines. Getting this right matters most for CTV requests, where buyers filter on devicetype: 3.
| Value | Name | Meaning |
|---|---|---|
1 | Mobile/Tablet - General | Interchangeable mobile class when 4 or 5 is unknown. |
2 | Personal Computer | Desktop and laptop browsers. |
3 | Connected TV | Smart TVs; the CTV signal exchanges key on. |
4 | Phone | Specifically a phone, more precise than 1. |
5 | Tablet | Specifically a tablet, more precise than 1. |
6 | Connected Device | Consoles, streaming boxes and similar non-TV devices. |
7 | Set Top Box | Operator set top boxes. |
8 | OOH Device | Digital out-of-home screens. |
Connection type (device.connectiontype)
AdCOM List: Connection Types.
| Value | Name |
|---|---|
1 | Ethernet; Wired Connection |
2 | WIFI |
3 | Cellular Network - Unknown Generation |
4 | Cellular Network - 2G |
5 | Cellular Network - 3G |
6 | Cellular Network - 4G |
7 | Cellular Network - 5G |
Video placement: plcmt and the legacy placement
video.plcmt uses AdCOM List: Plcmt Subtypes - Video, added alongside the 2.6-202303 update that deprecated video.placement. The two lists are not a rename: the old five values map onto four new ones with stricter definitions (sound-on is part of what makes something Instream now). Full story in placement vs plcmt.
plcmt (current)
| Value | Name | Meaning |
|---|---|---|
1 | Instream | Sound on by default, video is the primary content. |
2 | Accompanying Content | Player beside text or graphical content, plays on entering the viewport. |
3 | Interstitial | No video content; takes over the viewport, cannot scroll away. |
4 | No Content/Standalone | No video content; slideshows, feeds, sticky or floating players. |
placement (deprecated, 2.6-202303)
| Value | Name | Meaning |
|---|---|---|
1 | In-Stream | Pre-, mid-, post-roll against requested video content. |
2 | In-Banner | Video inside display banner inventory. |
3 | In-Article | Player loading between paragraphs of editorial content. |
4 | In-Feed | Inside content, social, or product feeds. |
5 | Interstitial/Slider/Floating | Always on screen while displayed. |
Playback methods (video.playbackmethod)
AdCOM List: Playback Methods. The field is an integer array, but the 2.6 spec advises relying on the first element only, since it may become a single integer in a future version.
| Value | Name | Meaning |
|---|---|---|
1 | Initiates on Page Load with Sound On | |
2 | Initiates on Page Load with Sound Off by Default | |
3 | Initiates on Click with Sound On | |
4 | Initiates on Mouse-Over with Sound On | |
5 | Initiates on Entering Viewport with Sound On | |
6 | Initiates on Entering Viewport with Sound Off by Default | |
7 | Continuous Playback | Player keeps playing additional media until the user stops it. |
API frameworks (banner.api, video.api, audio.api, native.api)
AdCOM List: API Frameworks. Declares what the placement supports; an API not listed is assumed unsupported.
| Value | Name | Meaning |
|---|---|---|
1 | VPAID 1.0 | |
2 | VPAID 2.0 | |
3 | MRAID 1.0 | |
4 | ORMMA | |
5 | MRAID 2.0 | |
6 | MRAID 3.0 | |
7 | OMID 1.0 | Open Measurement. |
8 | SIMID 1.0 | |
9 | SIMID 1.1 | |
500+ | Vendor-specific codes |
Creative attributes (battr, attr)
AdCOM List: Creative Attributes, values 1 through 18 plus vendor-specific 500+. Used as battr (blocked attributes) on banner, video, audio, and native request objects, and as attr (declared attributes) on the response Bid. The most commonly seen values:
| Value | Name | Meaning |
|---|---|---|
1 | Audio Ad (Autoplay) | |
2 | Audio Ad (User Initiated) | |
3 | Expandable (Automatic) | |
6 | In-Banner Video Ad (Autoplay) | |
8 | Pop (e.g., Over, Under, or Upon Exit) | |
13 | User Interactive (e.g., Embedded Games) | |
14 | Windows Dialog or Alert Style | |
16 | Ad Provides Skip Button | Pair with video.skip on the request side. |
18 | Responsive; Sizeless; Fluid | |
500+ | Vendor-specific codes |
Protocols (video.protocols, audio.protocols)
AdCOM List: Creative Subtypes - Audio/Video. In practice this is the VAST version list, with each version split into an inline and a Wrapper entry.
| Value | Name | Meaning |
|---|---|---|
1 | VAST 1.0 | |
2 | VAST 2.0 | |
3 | VAST 3.0 | |
4 | VAST 1.0 Wrapper | |
5 | VAST 2.0 Wrapper | |
6 | VAST 3.0 Wrapper | |
7 | VAST 4.0 | |
8 | VAST 4.0 Wrapper | |
9 | DAAST 1.0 | Digital audio ad serving; audio support moved into VAST as of 4.1. |
10 | DAAST 1.0 Wrapper | |
11 | VAST 4.1 | |
12 | VAST 4.1 Wrapper | |
13 | VAST 4.2 | |
14 | VAST 4.2 Wrapper | |
15 | VAST 4.3 | |
16 | VAST 4.3 Wrapper |
Position (pos)
AdCOM List: Placement Positions, used as pos on banner and video objects. Also IQG-derived.
| Value | Name | Meaning |
|---|---|---|
0 | Unknown | |
1 | Above The Fold | |
2 | Locked | Fixed position. |
3 | Below The Fold | |
4 | Header | |
5 | Footer | |
6 | Sidebar | |
7 | Fullscreen |
Linearity (video.linearity)
AdCOM List: Linearity Modes. This describes the expected VAST response, not the player inventory type; that is what plcmt is for.
| Value | Name | Meaning |
|---|---|---|
1 | Linear | VAST response with video assets. |
2 | Non-Linear (i.e., Overlay) | VAST response with a banner or overlay. |
FAQ
Where are OpenRTB enum values defined?
Since OpenRTB 2.6, the request-side enumerated lists live in the AdCOM 1.0 specification, referenced from the 2.6 field tables as AdCOM lists; no-bid and loss reason codes live in the OpenRTB 3.0 document. In OpenRTB 2.5 and earlier the same lists were section 5 of the OpenRTB document itself. Values match across the two homes; only the location changed.
What do enum values of 500 and above mean?
Where a list says so (auction type, API frameworks, creative attributes, no-bid reasons, and others), values 500 and greater are reserved for exchange-specific or vendor-specific use. They are only meaningful to partners who agreed on them beforehand, so a validator can accept them but cannot tell you what they mean.
Is video.placement still valid in OpenRTB 2.6?
It parses, but it was deprecated in the 2.6-202303 update in favor of video.plcmt, which uses a different four-value list. Send plcmt; keep placement only for partners that have not migrated, and never assume the two lists share meanings.
Validate the enums you send
A devicetype of 9 or a plcmt value on the old placement list will not throw an error anywhere; it just misprices or drops your inventory. The bid request tester checks values against the documented lists and flags deprecated fields like video.placement with stable rule IDs (openrtb.field.deprecated, openrtb.field.undefined). The rule catalog lists every check, and the same engine runs from the CLI in CI.