Blog · Spec release
No more 2.7: how OpenRTB ships now, and why your parser should care
There is no OpenRTB 2.7, and under the current release process there may never be one in the form the version numbers of 2.x once implied. Since November 2022, IAB Tech Lab has shipped every non-breaking change to the spec as a dated snapshot of 2.6. Nine of them exist as of this writing, and each one adds, deprecates, or moves fields that a request built against an earlier snapshot will not have.
The policy, in the spec's own words
The openrtb2.x repository's release process documentation states it plainly: "As of OpenRTB 2.6-202211, OpenRTB's version number is only incremented on breaking changes." Non-breaking additions, such as a new field, object, or enumerated value, ship instead as a dated snapshot of the same 2.6 line, cut roughly once a month when approved changes exist in the working branch. The same document calls this out as a deliberate break from earlier practice: "In versions of OpenRTB prior to 2.6, major version numbers represent breaking changes and minor version numbers represent non-breaking changes." Under the old scheme, a non-breaking addition might have produced a 2.6 or 2.7. Under the current one, it produces a new date code on 2.6, and the major.minor number stays put until something actually breaks compatibility.
That is why there is no 2.7 to wait for. The version number most integrations quote, 2.6, has been stable since the spec went final in April 2022. What has moved underneath it is nine snapshots of additions, deprecations, and field relocations, documented one release at a time rather than bundled into a version bump.
The full timeline: nine snapshots since 2.6 shipped
2.6-202210 is the GitHub repository's own baseline tag, carrying no changes beyond the April 2022 final spec; the working policy quote above is attached to the following snapshot, 2.6-202211, which is also the first release to ship new fields under the current rules.
| Snapshot | What it added |
|---|---|
2.6-202204 | The 2.6 Final spec (April 2022). Added bid.apis, bid.mtype, cattax taxonomy selection, imp.rwdd, imp.ssai, the pod-bidding fields (maxseq, poddur, podid, podseq, mincpmpersec, slotinpod), rqddurs, BCP-47 language tags, the AUCTION_MIN_TO_WIN macro, the schain and eids object families, and device.sua. Deprecated the legacy sequence, device-hash, demographic, and single-api fields. Moved regs.ext.gdpr and user.ext.consent into core objects. |
2.6-202210 | The first tag cut in the openrtb2.x GitHub repo. Its own release notes describe it as the same 2.6 spec published in April 2022, with no new changes yet proposed or included. |
2.6-202211 | Added the Qty and DOOH objects (imp.qty, bidrequest.dooh) for digital-out-of-home, moved inventorypartnerdomain from ext into Site and App, and added GPP consent signaling (regs.gpp, regs.gpp_sid). The release notes also introduced the versioning policy covered below. |
2.6-202303 | Added imp.refresh and refresh.refsettings, deprecated imp.video.placement in favor of the new imp.video.plcmt, and added the AUCTION_IMP_TS macro. |
2.6-202309 | Added bidrequest.acat, deal.guaranteed and deal.mincpmpersec, and duration-aware floor objects on imp.video, imp.audio, and deal (durfloors). |
2.6-202402 | Added imp.video.poddedupe for pod deduplication signaling. |
2.6-202409 | Added cookie-sync guidance in an appendix and the EID fields eid.inserter, eid.matcher, and eid.mm. |
2.6-202501 | Added content.gtax and content.genres for genre taxonomy on the Content object. |
2.6-202505 | Added data.cids, extended content identifiers on Data objects. |
Why "we support 2.6" stopped being precise
A vendor claiming OpenRTB 2.6 support today could mean anything from the April 2022 baseline to the May 2025 snapshot, and the gap between those two is not cosmetic.video.placement is deprecated as of 2.6-202303 in favor of video.plcmt, a field with a different enum, not a renamed copy of the old one. regs.gpp and regs.gpp_sid did not exist before 2.6-202211. A parser or fixture set built against the 2022 baseline has no way to represent digital-out-of-home requests, duration-aware price floors, or genre taxonomy on Content, because none of those existed yet at that snapshot. None of this shows up as an error in a schema-less pipeline; it shows up as silently dropped fields, or as a validator flagging a field as unknown when the actual problem is that the validator is checking against the wrong date.
The practical consequence is that "OpenRTB 2.6" is no longer specific enough to be a compatibility claim on its own. Two exchanges can both be correct and still disagree on a bid request, because they are each correct against a different month.
What this means for parsers, fixtures, and validation
Three practices follow directly from a spec that ships this way:
- Name the snapshot, not just the minor version, in integration docs, partner contracts, and internal wikis. "2.6-202309" tells a counterpart exactly which fields to expect; "2.6" does not.
- Re-run fixtures against new snapshots on a cadence, not only when something breaks. A field can move from deprecated to removed, or a new field can become the one your buyers expect, without your traffic changing at all.
- Treat deprecation notices as a clock, not a suggestion.
imp.video.placementhas been deprecated since2.6-202303; it still works, but a parser that only understands the old field will eventually be reading a signal that fewer buyers are updating on the other end.
The site's own dated snapshots explainer covers the mechanics of how rtblint tracks this; the point here is that the practice of pinning to a snapshot is now a spec-mandated one, not a validator-specific convenience.
Pin your validation to a snapshot
The browser tester lets you pick a specific dated snapshot before validating a bid request, so a deprecated or moved field is reported against the version you actually target rather than the newest one. The Rust CLI takes the same snapshot argument for CI:
rtblint validate request.json --version 2.6-202309
Every diagnostic id rtblint can emit, including the ones that fire for a deprecated, moved, or not-yet-available field at a given snapshot, is listed in the rule reference, and the underlying rule catalog for each tracked version is browsable in the rules index.