Guides
OpenRTB 2.6 vs 3.0
OpenRTB 3.0 is not the version after 2.6. It is a ground-up redesign from 2018: a thin transaction envelope (Openrtb.request with item and context) that delegates all domain objects to AdCOM 1.0 and builds in ads.cert request signing. It is not backward compatible with 2.x, adoption never took off, and the IAB Tech Lab keeps shipping dated updates to 2.6 instead. In practice, 2.6 is the protocol; 3.0 supplies its enum lists and reason codes.
A different architecture, not a sequel
OpenRTB 2.x is one monolithic spec: the BidRequest object defines the auction fields and the domain fields (site, app, device, user, video) in a single document. 3.0 splits that into layers. Layer 1 is transport (HTTPS), layer 2 is format (JSON), layer 3 is the transaction, which is all the OpenRTB 3.0 document defines, and layer 4 is the domain model, delegated to AdCOM 1.0 by default. The envelope names its domain layer explicitly: domainspec (default "adcom") and domainver.
A minimal 3.0 request makes the layering visible:
{
"openrtb": {
"ver": "3.0",
"domainspec": "adcom",
"domainver": "1.0",
"request": {
"id": "0123456789ABCDEF",
"tmax": 150,
"item": [
{ "id": "1", "flr": 2.5, "flrcur": "USD", "spec": { "placement": { /* AdCOM */ } } }
],
"context": { "site": { /* AdCOM */ }, "device": { /* AdCOM */ }, "user": { /* AdCOM */ } }
}
}
}The transaction layer only knows it is selling item entries under some context. What an item is (a video placement, a banner slot, a DOOH screen) is entirely AdCOM's business, described in item.spec. In 2.6, by contrast, the imp object and its video or banner children are defined inline; see the bid request anatomy for that shape.
Concept mapping: 2.6 to 3.0
| OpenRTB 2.6 | OpenRTB 3.0 | Note |
|---|---|---|
| BidRequest (top-level object) | Openrtb envelope with a request attribute (Request object) | The envelope carries ver, domainspec (default "adcom"), and domainver |
| imp array | request.item array (Item objects) | An item is anything offered for sale, not only an ad impression |
| imp.banner / imp.video / imp.audio / imp.native | item.spec holding an AdCOM Placement object | Media-type detail moves entirely into the domain layer |
| imp.bidfloor / imp.bidfloorcur | item.flr / item.flrcur | Same semantics, renamed |
| site / app on the BidRequest | request.context.site / context.app (AdCOM), plus context.dooh | One distribution channel per request |
| device, user, regs | request.context.device / user / regs (AdCOM) | Same concepts, defined by AdCOM instead of OpenRTB |
| bcat, badv, battr spread across the request | context.restrictions (AdCOM Restrictions object) | Blocking rules consolidated in one place |
| source (tid, pchain, schain) | request.source, extended with ads.cert fields: ts, ds, dsmap, cert, digest | Cryptographic request signing is built in |
| BidResponse with seatbid.bid | Openrtb envelope with response, then seatbid.bid | bid.item references the item id it answers |
| bid.adm markup string | bid.media holding an AdCOM Ad object | The creative is a structured object, not opaque markup |
Auction mechanics carry over with familiar names: id, tmax, at, cur, and seat all live on the Request object.
Built-in security: ads.cert
3.0 was designed alongside ads.cert Signed Bid Requests. The Source object carries a digital signature (ds), the fields it covers (dsmap), the signer's certificate reference (cert), and optionally the full digest for debugging, so a buyer can verify the request originated from the claimed publisher and was not modified along the path. 2.x has no equivalent mechanism in the protocol; it addresses supply-path trust with ads.txt, sellers.json, and the SupplyChain object instead.
Why adoption stayed on 2.x
A protocol change with no backward compatibility needs every exchange, DSP, and SSP to run dual stacks during a long transition, and the payoff in 2018 was mostly architectural cleanliness plus ads.cert, which itself needed ecosystem-wide key infrastructure. Meanwhile the things buyers and sellers actually wanted (CTV pod bidding, GPP, structured user agents, DOOH) shipped in 2.6 and its dated updates. The IAB Tech Lab formalized that reality: since the 2.6-202211 update, the 2.x line receives monthly-cadence updates and the version number only changes on breaking changes. See OpenRTB versions for the full timeline and 2.5 vs 2.6 for what the current line added.
3.0 still matters in three ways. First, AdCOM: since 2.6, every enumerated list your 2.x integration validates against (device types, placement subtypes, creative attributes) is maintained in AdCOM 1.0, the domain half of the 3.0 design; the enums reference maps them. Second, no-bid and loss reason codes used by 2.6 are maintained in the OpenRTB 3.0 document. Third, a few greenfield or specialized integrations do speak native 3.0, so you may still meet an Openrtb envelope in the wild.
FAQ
Is OpenRTB 3.0 newer than 2.6?
As a document, 3.0 was published in 2018 and predates 2.6 (2022). It is a parallel redesign, not the next release. The IAB Tech Lab keeps evolving 2.6 through dated updates, so 2.6 is where new capabilities like GPP, DOOH, and duration floors actually land.
Is OpenRTB 3.0 backward compatible with 2.x?
No. The object model is different from the root down: an Openrtb envelope instead of a bare BidRequest, item instead of imp, and AdCOM objects for all domain data. A 2.6 request cannot be reinterpreted as a 3.0 request; supporting both means running two parsers.
Does OpenRTB 2.6 use AdCOM?
For enumerated lists, yes. Since 2.6, device types, placement subtypes, API frameworks, and the other enums are maintained in AdCOM 1.0 and the 2.6 spec links to them. The 2.6 object model itself (BidRequest, imp, site, app) remains defined in the OpenRTB 2.6 document.
Validate what you actually send
rtblint validates OpenRTB 2.6 bid requests today, in the browser and in CI. Paste a request into the bid request tester to catch undefined fields (openrtb.field.undefined), moved paths, and type mismatches against the current 2.6 snapshot. Object catalogs exist for 2.0 through 3.0, so version-aware field checks cover the 3.0 envelope too; full 3.0 rule depth is on the roadmap.