Guides
What is AdCOM? OpenRTB's companion object model
If you have read the OpenRTB 2.6 spec you have hit dozens of links that point out of the document to something called AdCOM. That is not a footnote; it is where half the meaning of a bid request now lives. AdCOM is the Advertising Common Object Model, and understanding the split between it and OpenRTB explains why enum values moved and where to look them up.
The one-line definition
AdCOM is an IAB Tech Lab companion specification that defines common objects and values expected to be used across many IAB Tech Lab specifications. Instead of every protocol redefining what a "device type" or a "creative attribute" is, they all reference one shared model. OpenRTB is one consumer of it; so are other Tech Lab standards.
Why OpenRTB 2.6 moved its lists there
Through OpenRTB 2.5, the enumerated lists, device types, connection types, API frameworks, creative attributes, and the rest, lived in Section 5 of the OpenRTB document itself. OpenRTB 2.6 removed that section entirely and pointed every reference at AdCOM instead. The spec is explicit about the reason: keeping the lists in AdCOM lets them iterate more rapidly than the base protocol. A new device type or API framework can be added to an AdCOM list without cutting a new OpenRTB version, which fits the dated-snapshot model where the version number only moves on breaking changes.
What AdCOM defines
Two kinds of thing, and the enumerated lists are the part most OpenRTB integrations touch daily:
- Enumerated lists. The value tables OpenRTB fields reference: device types, connection types, placement positions, playback methods, API frameworks, creative attributes, category taxonomies, and more. When a 2.6 field says "refer to List: Creative Attributes in AdCOM 1.0," the numbers behind
battrcome from AdCOM, not OpenRTB. - Context and placement objects. AdCOM also models the site, app, DOOH, user, and device context and the placement of an ad. In OpenRTB 2.6 these still appear as native OpenRTB objects, but in OpenRTB 3.0 the request is built directly on AdCOM objects.
Fields like cattax (which taxonomy bcat uses), battr (blocked creative attributes), and pos (ad position) all resolve their legal values against AdCOM lists. The enum reference notes where each one moved.
AdCOM and OpenRTB 3.0
AdCOM is also the foundation of OpenRTB 3.0. Where 2.x is a single self-contained protocol, 3.0 is a layered design: a thin transaction layer (the bid request and response envelope) sits on top of AdCOM, which supplies the domain objects. That is why 2.6 and 3.0 are better understood as different architectures than as an upgrade, and why most traffic still runs 2.6. AdCOM is the shared layer that both versions, and the newer agentic work, build on.
What it means for validation
Because the value tables live in AdCOM, validating a bid request means checking some fields against AdCOM lists, not the OpenRTB document. A device type or placement value that was valid under an old list, or that a validator hard-codes from an outdated copy, is exactly the kind of drift that costs bids without erroring. rtblint tracks documented enum values as part of its rule set; paste a request into the tester or run the CLI to check them.