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, and the field reference, including which snapshot each value is actually valid in, in video.plcmt. AdCOM 1.0-202607 extended the list with 5 through 9 for the CTV Ad Portfolio formats, covered in the 202607 release notes.
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. |
5 | Pause | Added in AdCOM 1.0-202607. Shown when the viewer pauses requested video content. |
6 | Screensaver | Added in AdCOM 1.0-202607. Shown when an OS or app screensaver starts. |
7 | Overlay | Added in AdCOM 1.0-202607. Over program content, outside the traditional break. |
8 | Squeezeback | Added in AdCOM 1.0-202607. Content is resized to share the screen with the ad. |
9 | In-scene | Added in AdCOM 1.0-202607. Branded elements composited into the content itself. |
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 without any specific user interaction with Sound On | Reworded in AdCOM 1.0-202607; was "Initiates on Page Load". |
2 | Initiates without any specific user interaction Sound Off by Default | Reworded in AdCOM 1.0-202607; was "Initiates on Page Load". |
3 | Initiates on Click with Sound On | |
4 | Initiates on Mouse-Over or cursor over with Sound On | Reworded in AdCOM 1.0-202607. |
5 | Initiates on Entering Viewport or scrolling into view with Sound On | Reworded in AdCOM 1.0-202607. |
6 | Initiates on Entering Viewport or scrolling into view with Sound Off by Default | Reworded in AdCOM 1.0-202607. |
7 | Continuous Playback | Player keeps playing additional media until the user stops it. |
8 | Initiated by user pausing content, Sound on | Added in AdCOM 1.0-202607. |
9 | Initiated by user pausing content, Sound off | Added in AdCOM 1.0-202607. |
10 | Initiated by idling (e.g. screensaver), Sound on | Added in AdCOM 1.0-202607. |
11 | Initiated by idling (e.g. screensaver), Sound off | Added in AdCOM 1.0-202607. |
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 23 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 commonly seen values, plus everything added in AdCOM 1.0-202607:
| 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 | |
19 | Contains advertiser QR Code | Added in AdCOM 1.0-202607. |
20 | Support alpha channel transparency | Added in AdCOM 1.0-202607. |
21 | Static Visual | Added in AdCOM 1.0-202607. No perceptible motion, even in a video container. |
22 | Limited Motion (Cinemagraph) | Added in AdCOM 1.0-202607. Subtle looped motion in a static composition. |
23 | Full-Motion Video | Added in AdCOM 1.0-202607. Continuous or scene-level motion. |
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 | |
8 | Partial Screen | Added in AdCOM 1.0-202607. |
9 | Top Left | Added in AdCOM 1.0-202607. |
10 | Top Right | Added in AdCOM 1.0-202607. |
11 | Frame the content | Added in AdCOM 1.0-202607. |
12 | Double box | Added in AdCOM 1.0-202607. |
13 | Double box with background | Added in AdCOM 1.0-202607. |
14 | Bottom Left | Added in AdCOM 1.0-202607. |
15 | Bottom Right | Added in AdCOM 1.0-202607. |
16 | L shape | Added in AdCOM 1.0-202607. Squeezeback geometry. |
17 | Reversed L shape | Added in AdCOM 1.0-202607. Squeezeback geometry. |
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.