Guides
OpenRTB 2.5 vs 2.6: what changed
OpenRTB 2.6 (April 2022) added ad pod bidding for CTV, promoted regs.gdpr, user.consent, source.schain, and user.eids from extensions to first-class fields, moved every enumerated list into AdCOM 1.0, and switched to dated updates instead of new minor versions. GPP and plcmt arrived through those updates. The full comparison is below.
Side by side
| Area | OpenRTB 2.5 | OpenRTB 2.6 |
|---|---|---|
| CTV ad pods | No pod concept; one imp per slot with no grouping | podid, podseq, slotinpod, maxseq, poddur, mincpmpersec, rqddurs on Video and Audio |
| GDPR flag | regs.ext.gdpr (extension) | regs.gdpr (first-class) |
| TCF consent string | user.ext.consent (extension) | user.consent (first-class) |
| Supply chain | source.ext.schain (extension) | source.schain with documented SupplyChain and SupplyChainNode objects |
| Extended IDs | user.ext.eids (extension) | user.eids with documented EID and UID objects |
| Enumerated lists | Section 5 of the 2.5 spec itself | Removed from the spec; all references point to AdCOM 1.0 lists |
| User-Agent | device.ua string only | device.sua structured UserAgent object plus BrandVersion |
| Keywords | Comma-separated keywords string | kwarray string arrays on Site, App, Content, and User |
| Category taxonomy | IAB Content Category 1.0 assumed | cattax declares the taxonomy on BidRequest, Site, App, Publisher, Content, Producer, Bid |
| Rewarded and SSAI | Exchange-specific extensions | imp.rwdd and imp.ssai |
| Versioning | New minor version per change batch | Dated updates (2.6-202211 onward); version only increments on breaking changes |
Pod bidding: the headline feature
2.5 had no way to describe a CTV ad break. 2.6 added a set of fields to the Video and Audio objects that group impressions into pods: podid ties impressions in the same break together, podseq gives the pod's position in the stream, and slotinpod signals whether the seller can guarantee a slot position (first, last) inside the pod. Dynamic pods, where the seller sells a block of time rather than fixed slots, use poddur (total fillable seconds), maxseq (max ads in the pod), mincpmpersec (a per-second price floor), and rqddurs (exact permitted durations). The 2.6-202309 update added durfloors, an array of DurFloors objects expressing floor price by duration range. Details and request shapes are on the CTV and pod bidding page.
Privacy and identity fields got real homes
In 2.5, GDPR signals lived in extensions by IAB advisory: regs.ext.gdpr and user.ext.consent. 2.6 made them first-class as regs.gdpr and user.consent. The 2.6-202211 update then added regs.gpp and regs.gpp_sid for the Global Privacy Platform, which supersedes the per-regulation strings for new integrations. The same promotion happened to identity and supply-path data: source.ext.schain became source.schain with documented SupplyChain and SupplyChainNode objects, and user.ext.eids became user.eids. See privacy signals and the supply chain object for field-level detail.
Enums moved out, and other structural changes
2.6 deleted its own Section 5. Every enumerated list (device types, API frameworks, creative attributes, placement subtypes) is now maintained in AdCOM 1.0, so new values can ship without touching the OpenRTB document. No-bid and loss reason codes live in the OpenRTB 3.0 document. The enums reference maps each field to its list. Beyond that, 2.6 added imp.rwdd (rewarded inventory), imp.ssai (server-side ad insertion status), device.sua (structured user agent), kwarray keyword arrays, cattax taxonomy declarations, BCP 47 language fields (langb), and mtype on the bid so buyers declare the markup type they return.
Deprecations came with it. 2.6 deprecated video.sequence, audio.sequence, the hashed device IDs (didsha1, didmd5, dpidsha1, dpidmd5, macsha1, macmd5), user.yob, user.gender, and bid.api. It removed fields already deprecated in 2.5: banner.wmax, hmax, wmin, hmin, video.protocol, and content.videoquality.
2.6 evolves through dated updates
Since 2.6-202211, the IAB Tech Lab increments the version number only for breaking changes. Everything else lands as a dated update to 2.6, which is why plcmt and GPP are "2.6 fields" that do not appear in the original April 2022 PDF:
| Update | What it added |
|---|---|
2.6-202211 | GPP support (regs.gpp, regs.gpp_sid), DOOH and Qty objects, inventorypartnerdomain promoted from ext. Also established the monthly update cadence. |
2.6-202303 | plcmt on Video, deprecating placement. Refresh and RefSettings objects, AUCTION_IMP_TS macro. |
2.6-202309 | DurFloors object: durfloors arrays on Video, Audio, and Deal for duration-based floor pricing. acat on BidRequest. |
2.6-202402 | poddedupe on Video for pod-level creative deduplication. |
2.6-202409 | EID object gained inserter, matcher, and mm (match method) attributes. |
2.6-202501 | gtax and genres for content genre taxonomies. |
2.6-202505 | cids on the Data object; genres type corrected to a string array. |
The placement to plcmt change is the one most likely to bite a migrating video integration; it has its own guide because the two enums do not map one to one.
Migration checklist: 2.5 to 2.6
- Move
regs.ext.gdprtoregs.gdpr,user.ext.consenttouser.consent,source.ext.schaintosource.schain, anduser.ext.eidstouser.eids. Many partners read both paths during transition, but new integrations expect the first-class fields. - Add
regs.gppandregs.gpp_sidif you handle US state privacy laws or want one consent transport going forward. - For video, set
plcmtfrom the new AdCOM list and keepplacementonly for legacy buyers. - Drop removed fields:
banner.wmax/hmax/wmin/hmin,video.protocol,content.videoquality. Stop populating the deprecated hashed device IDs,user.yob, anduser.gender. - If you transact CTV, populate the pod fields (
podid,podseq,slotinpod, and the dynamic-pod trio) instead of exchange-specific extensions. - Point your enum validation at AdCOM 1.0 lists rather than the 2.5 Section 5 tables, and declare
cattaxif you send category IDs from a taxonomy newer than 1.0.
For the wider version story, including 3.0, see OpenRTB versions and the 2.6 vs 3.0 guide.
FAQ
Is OpenRTB 2.6 backward compatible with 2.5?
Largely, yes. A valid 2.5 request is structurally close to a valid 2.6 request. The gaps: fields deprecated in 2.5 (banner wmax/hmax/wmin/hmin, video.protocol, content.videoquality) were removed in 2.6, extension fields like regs.ext.gdpr and source.ext.schain have first-class homes, and enum references now point to AdCOM 1.0.
Will there be an OpenRTB 2.7?
Only if the IAB Tech Lab ships a breaking change. Since 2.6-202211, the version number is frozen and non-breaking additions land as dated updates (2.6-202303, 2.6-202309, and so on). New fields and enum values arrive without a version bump.
Where did the enumerated lists in Section 5 go?
OpenRTB 2.6 removed its own enum section. Device types, API frameworks, video placement subtypes, and the rest now live in AdCOM 1.0, and the 2.6 spec links to those lists. No-bid and loss reason codes are the exception: they live in the OpenRTB 3.0 document.
Validate the migration
The fastest way to find 2.5 leftovers is to run a real request through the bid request tester: rtblint validates against OpenRTB 2.6 and flags fields at moved paths (openrtb.field.moved), deprecated fields (openrtb.field.deprecated), and anything the spec does not define (openrtb.field.undefined). The same checks run in CI with the CLI: rtblint validate request.json.