What changed in OpenRTB 2.6, and which release does a partner run?
Part of Supply path transparency
The short answer
OpenRTB 2.6 is the IAB Tech Lab bid request protocol published in April 2022 and extended since by dated releases, the latest 2.6-202606 of June 11, 2026. It added ad pod bidding, a formal place for the SupplyChain object and, later, the plcmt video field and duration based deal floors. Partners can all say 2.6 yet support different fields.
Key takeaways
- Since 2.6-202211 the version number changes only on breaking changes, so new fields arrive as dated releases that all still count as 2.6.
- The x-openrtb-version header carries only major and minor numbers, so it cannot show which dated release a partner implements.
- plcmt replaced the placement field in 2.6-202303 to match updated video definitions, and publishers may send both during the transition.
- Deal floors by duration and the guaranteed flag arrived in 2.6-202309, after the original 2.6 publication.
What changed in OpenRTB 2.6?
The OpenRTB 2.x releases page (opens in a new tab) records the history. Its first entry, 2.6-202210, is "the same version of the OpenRTB 2.6 spec that was published in April 2022", and later entries add fields month by month. The repository's versioning policy (opens in a new tab) explains why they are not called 2.7: as of 2.6-202211 the version number is incremented only on breaking changes. The OpenRTB overview lists the baseline changes from 2.5; the table below follows the dated releases a buyer meets in practice.
| Release (date published) | What it added | Question for a partner |
|---|---|---|
| 2.6-202211 (November 17, 2022) | DOOH object, GPP privacy string in Regs, inventorypartnerdomain moved from ext into Site and App | Do you read inventorypartnerdomain in the standard field or still in ext? |
| 2.6-202303 (April 5, 2023) | Refresh and RefSettings objects, the AUCTION_IMP_TS macro, the plcmt video field, placement deprecated | Do you send plcmt, placement or both on video? |
| 2.6-202309 (September 28, 2023) | acat in BidRequest, the DurFloors object, new Deal attributes for guaranteed deals, mincpmpersec and durfloors | Which floor fields do you set on video deals? |
| 2.6-202402 (February 20, 2024) | poddedupe in Video, marked provisional | Do you apply pod deduplication, and how is it signaled? |
| 2.6-202409 (September 23, 2024) | inserter, matcher and mm in EID; Appendix C on cookie based ID syncing | How do you disclose who matched each extended ID? |
| 2.6-202501 (January 27, 2025) | gtax and genres in Content, with Content Taxonomy 3.1 in AdCOM | Do you send genres for CTV, and from which taxonomy? |
| 2.6-202505 (May 20, 2025) | cids in the Data object for extended content identifiers | Do you pass content IDs, and from which provider? |
| 2.6-202606 (June 11, 2026) | realtime and firstbroadcast in Content, new discount macros | Can you flag live programming on the request? |
Why did the video placement field change?
The 2.6-202303 release added plcmt and deprecated placement. The OpenRTB implementation guide (opens in a new tab) says the new attribute gives publishers a way to signal video inventory that more closely aligns with the updated ad format guidelines without breaking existing workstreams. A new field was needed because the definitions themselves moved: the old list and the new list can describe the same player differently, so reusing one field would have changed the meaning of numbers already in buyers' rules.
During the transition the guide shows publishers sending both fields. Its two cases are legacy placement 1 with plcmt 1 for in-stream video, and legacy placement 3, in-article, with plcmt 4, no content or standalone. A buyer's rules should read plcmt first and fall back to placement only when plcmt is absent. The video PMP guide lists each plcmt value for deal terms.
What do the ad pod fields in OpenRTB 2.6 describe?
Pod bidding arrived with the 2.6 baseline. The implementation guide defines an ad pod as an ad break of the kind seen in TV like viewing or heard on a radio stream, and names three structures: a structured pod, where the number, order and length of slots are fixed; a dynamic pod, where only the total length and maximum number of ads are set; and a hybrid pod that combines both.
| Field | What it tells the bidder |
|---|---|
| podid | Impressions sharing this value belong to the same pod |
| podseq | The pod's position in the content stream, such as the first or last break |
| slotinpod | The seller can guarantee delivery in that slot position |
| poddur and maxseq | Total seconds advertisers may fill in a dynamic pod, and the most ads it can hold |
| rqddurs | Exact creative lengths accepted, for live TV where other lengths leave dead air; excludes minduration and maxduration |
| mincpmpersec | A floor per second of ad length for the dynamic portion of a pod |
Two of the guide's recommendations matter to buyers. Sellers should signal a first or last slot only if they can absolutely guarantee it. And buyers should expect the seller to build the final pod: a buyer that submits several bids for one pod may see anywhere from none to all of them used, mixed with other buyers' ads.
Where does the SupplyChain object sit in OpenRTB 2.6?
OpenRTB 2.6 made schain a recommended attribute of the Source object, beside fd, tid and pchain. The SupplyChain specification (opens in a new tab) says the object should be in BidRequest.Source.schain in 2.6 or later, in BidRequest.Source.ext.schain in 2.5, and in BidRequest.ext.schain for 2.4 or earlier. The rules for building the chain did not change with the move.
Reading schain in a stream of mixed version requests
- Check source.schain first. A request declaring 2.6 should carry the chain there.
- Fall back to source.ext.schain. Some 2.6 senders still fill the 2.5 location; Prebid's supply chain module page says Prebid 10 copies its schain settings into ortb2.source.ext.schain unless the publisher sets the standard field.
- Treat two different chains as an error. If both locations hold chains that disagree, log the request and ask the sender which one is authoritative.
- Record the chain with the version header. Pairing them shows which partners still send the old location, which is the conversation to have at the next review.
How each node is read is covered in the supply chain object guide.
How do buyers know which OpenRTB version a partner supports?
The OpenRTB 2.6 specification (opens in a new tab) asks senders to pass the version in an HTTP header, x-openrtb-version: 2.6, so bidders can recognize it before parsing, and recommends that bidders return their own version in the response header. The header is specified as major and minor only. Because every dated release since 2.6-202211 is still 2.6, the header cannot separate a partner on the 2022 baseline from one on the June 2026 release.
Version questions to settle with each exchange before a deal
- The partner names the dated 2.6 release it implements, not only 2.6.
- The partner lists which fields added after the baseline it actually sends, such as plcmt, durfloors or genres.
- The partner confirms whether schain arrives in source.schain, source.ext.schain or both.
- A sample of live requests from the partner shows the fields it says it sends.
- The buyer's own platform documents which release it parses, so unread fields are known.
Recommended fields can be absent in any release, so a sample of logged requests is the only proof of what a partner sends. The bid request guide shows how to read one.
Which OpenRTB 2.6 fields carry deal terms?
Deal terms live in the Pmp and Deal objects, whose core fields are defined on the deal object guide. What 2.6 changed is the floor. The implementation guide says buyers bidding with a deal ID should use the floor guidance in the Deal object; if there is none, the Video or Audio object; and only then the Imp object. In the Deal object a seller should send one of mincpmpersec, durfloors or bidfloor.
| Field | Where and when | Why it matters |
|---|---|---|
| private_auction, at, wseat, bidfloor | Pmp and Deal, present in the 2.6 baseline | Who may bid and how the price is set |
| bidfloorcur on the Deal | Deal, present in the 2.6 baseline | It does not inherit the Imp currency; it is set explicitly or defaults to USD, which matters for CAD deals |
| wadomain | Deal, in the current specification | Limits the advertiser domains allowed to bid |
| guar | Deal, from 2.6-202309 | 1 means a guaranteed deal the bidder must bid on |
| mincpmpersec and durfloors | Deal, from 2.6-202309 per the release notes | Floors that change with ad length on video and audio deals |
What does a 2.6 version check look like on a real plan?
Fictional example
A tutoring center chain in Toronto, Hamilton and London
A fictional chain of tutoring and test preparation centers plans a CAD video deal for the winter exam season, on parenting, education and local news sites and on CTV apps read and watched in southern Ontario, in English. Two exchanges offer the inventory.
The desk asks each exchange which dated release it implements. One names 2.6-202309 and shows durfloors on its sample requests; the other names only 2.6, and its samples carry placement without plcmt and schain in source.ext.schain. The second exchange's deal also omits bidfloorcur, so the floor would be read as USD.
The desk updates its parser to read both schain locations, asks the second exchange to send plcmt and to set the deal currency to CAD, and writes the agreed fields onto the deal sheet before launch.
How does PlacementGraph prepare the site side of a 2.6 deal?
Frequently asked questions
Will there be an OpenRTB 2.7?
Only if a breaking change is needed. The repository's versioning policy says the version number is incremented only on breaking changes as of 2.6-202211, and that 2.7 should be considered a distinct version from 2.6. Non breaking additions keep arriving as dated 2.6 releases, roughly monthly when there are improvements to publish.
Does OpenRTB 2.6 cover digital out of home screens?
Yes, from 2.6-202211. That release added a DOOH object, and the specification says a bid request with a DOOH object must not contain a Site or App object. A Qty object carries a multiplier, the number of billable events deemed to occur if the opportunity is bought, and the specification's own example treats one DOOH opportunity as 14.2 impressions.
What does the acat field added in 2.6-202309 do?
acat lists allowed advertiser categories, the opposite of bcat, which blocks categories. The specification says only one of the two should be present, and that the taxonomy comes from the cattax field, with IAB Content Taxonomy 1.0 assumed if none is given. A request with acat admits only advertisers in those categories.
Is poddedupe safe to rely on in a CTV deal?
Treat it as provisional. The 2.6-202402 release added poddedupe to the Video object, and the specification marks it PROVISIONAL. It tells bidders which pod deduplication settings will be applied to bid responses. Where repeated ads in one break matter, confirm the seller's deduplication rules in the deal terms rather than relying on the field.
Sources
- OpenRTB 2.6 specification (opens in a new tab)IAB Tech Lab, OpenRTB 2.x repository
- OpenRTB 2.x releases (opens in a new tab)IAB Tech Lab, GitHub
- OpenRTB 2.x repository and versioning policy (opens in a new tab)IAB Tech Lab, GitHub
- OpenRTB 2.6 implementation guide (opens in a new tab)IAB Tech Lab, OpenRTB 2.x repository
- SupplyChain object specification (opens in a new tab)IAB Tech Lab, OpenRTB repository
- Module: Supply Chain Object (opens in a new tab)Prebid.org documentation
Researched and written by PlacementGraph Research. Read how we research, source and update these pages. Corrections: diana@placementgraph.com.