OpenRTB 2.6 explained: a bid request example, field by field

A request is one top-level BidRequest object. It holds an array of Imp objects, one per impression on offer. Each Imp carries exactly the media objects it allows: banner, video, audio or native. Around the impressions sit context objects: site or app (or dooh for screens), device, user, source and regs. The full object model is in section 3.1 of the OpenRTB 2.6 specification.

The transport rules are short. The exchange sends the request as HTTP POST with Content-Type: application/json and a version header. A bidder that does not want to bid returns HTTP 204 with no body, the cheapest option (OpenRTB 2.6, sections 2.1 and 2.5). The header looks like this:

A no-bid with a reason code is also valid. Reason code 2 means "Invalid Request" in the OpenRTB 3.0 list of no-bid reason codes, which OpenRTB 2.6 reuses:

The first example is a desktop visit to a German news article with one medium rectangle slot. The site runs header bidding, so the ad server makes the final call. GDPR applies, and the request also carries a private deal. All domains use the reserved .example and example.com names, IP addresses come from documentation ranges, and IDs are invented. Taxonomy IDs, enumerated values and the privacy strings are real values taken from the IAB Tech Lab repositories.

Three details in this request trip up new integrations. The deal floor carries its own currency field, because the spec says it does not inherit the impression's. The cattax on the BidRequest describes only bcat, while site.cattax describes the site categories, so one request can use two taxonomies at once. And fd set to 1 tells the buyer that winning this auction is not the end: an ad server downstream still compares the bid with other demand (OpenRTB 2.6, objects Source and Deal).

The second example is a live sports stream on a connected TV app in New York. The break is a hybrid pod. Impression 1 is a structured slot that the seller guarantees will play first. Impression 2 is a dynamic portion: up to three ads filling up to 90 seconds, the hybrid pattern in the implementation guide's pod examples. Both impressions share one podid, which is how a bidder knows they belong to the same break. Ads are stitched server-side. The supply reaches the buyer through a reseller, so the supply chain has two nodes.

The pod rules come from the implementation guide. Sellers should send either rqddurs or the minduration and maxduration pair, never both. Buyers should expect the seller to build the final pod and to drop or mix bids from several buyers (OpenRTB implementation guide, section 7.6). Floors follow a fixed order: a buyer bidding on a deal uses the deal's floor, then the video floor, then imp.bidfloor (implementation guide, section 7.11). The engineering of stitching and pods is covered in SSAI and CTV ad serving.

This example omits a GPP string on purpose. A live US request would usually carry gpp with gpp_sid 7 (the MSPA US National section) or a state section such as 8 for California (GPP Section Information). IAB Tech Lab revised the US National section for the Fifth Amended and Restated MSPA in commits dated 4 November 2026 (GPP repository commit, 4 November 2026). We did not want to print a sample string that no longer decodes.

The display response below bids on the open market for the medium rectangle. The CTV response sends three bids for the pod: one for the guaranteed first slot, one through the deal, and one that asks for the last slot of the dynamic portion.

The prices respect the floors. Bid 2 is a 15-second deal bid at 16.00, above the deal's 15.00 duration floor. Bid 3 is a 30-second open-market bid at 25.50, which works out to 0.85 per second, above the 0.75 mincpmpersec floor. In a first-price auction, the price you return is the price you pay, which is why most DSPs adjust it first; the mechanics are in bid shading explained. The ${AUCTION_MIN_TO_WIN} macro in the loss URL was added in 2.6 and is the feedback signal those models learn from (OpenRTB 2.6, section 4.4.1).

IAB Tech Lab now publishes 2.6 as dated releases. The table lists each one with the fields it added. For the wider comparison with 2.5 and 3.0, and what is actually used in the market, see OpenRTB 2.5 vs 2.6 vs 3.0.

No release after 2.6-202606 appeared on the repository's release page when we checked on 9 November 2026 (openrtb2.x releases). Because the version header still reads 2.6, a bidder cannot tell from the header alone which release the exchange implements. Ask each partner which release they target, and log unknown fields instead of rejecting the request.

The regs object says which rules apply to this request. The coppa flag marks child-directed traffic under the US Children's Online Privacy Protection Act. A gdpr value of 1 means the EU or UK GDPR applies, and the TCF consent string then travels in user.consent. The us_privacy field carries the older US Privacy string. The gpp field carries a Global Privacy Platform (GPP) string, and gpp_sid lists the section IDs that apply to this transaction (OpenRTB 2.6, Object: Regs).

A GPP string is a header plus one or more sections joined by a tilde. In the display example, DBABM is the header declaring one section, and the part after the tilde is a TCF v2 section. That exact string is "GPP String Example 1" in the GPP Consent String Specification. Section ID 2 is the EU TCF v2 section, 7 is US National, and 6, the old US Privacy string, is marked deprecated (GPP Section Information).

One caveat applies to that example. Under TCF 2.3, a TC string must contain the Disclosed Vendors segment, which the April 2025 revision of the consent string spec made mandatory (TCF consent string and vendor list formats v2). The GPP specification's example predates that rule, so do not use it as a test of TCF 2.3 handling. The end-to-end consent flow, from CMP to bidder, is the subject of GPP and TCF implementation for engineers.

The SupplyChain object lists every company that sold or resold the impression. Each node names the exchange domain (asi) and the seller account at that exchange (sid). The first node is the publisher's own account; each reseller appends one more. complete set to 1 claims that no seller is missing (OpenRTB 2.6, Object: SupplyChainNode).

Buyers verify a chain against two public files. Each asi domain publishes a sellers.json listing its sid values, and the publisher's ads.txt must authorise the first node. In the CTV example, publisher.id is "4410" because the request comes from Exchange Beta, where SSP Alpha sells as seller 4410. If publisher.id and the last sid differ, that check fails. The checks are worked through in SupplyChain, ads.txt and sellers.json together.

The user.eids array carries identifiers from sources other than the exchange's own cookie. Each entry names the ID's source domain.

Release 2.6-202409 added three fields that say how the ID got there: inserter (who added it), matcher (who performed the match) and mm, the match method from AdCOM (2.6-202409 release notes). The AdCOM list defines 3 as an authenticated match, such as an email login or hashed email, and 4 as an observed first-party ID such as SharedID (AdCOM 1.0, List: ID Match Methods). The source domains in the examples, pubcid.org for SharedID and uidapi.com for UID2, are the ones Prebid documents (Prebid User ID module).

1. Sending rqddurs together with minduration or maxduration. The spec makes them mutually exclusive. Pick exact durations for live TV and a range for everything else (OpenRTB 2.6, Object: Video).
2. Returning slotinpod for a structured slot. In a structured pod the impid already identifies the slot. Buyers should return slotinpod only on dynamic portions, and only to demand the first or last position.
3. Pricing every duration off imp.bidfloor. When mincpmpersec or durfloors is present, a 30-second ad faces a higher floor than a 15-second ad. Bidders that ignore it send long creatives below the floor and see them rejected.
4. Assuming the deal floor uses the impression's currency. Deal.bidfloorcur defaults to USD unless the deal states otherwise.
5. Leaving cattax at its default. The default value 1 points to Content Category Taxonomy 1.0, which AdCOM now marks deprecated. Sending newer IDs without setting cattax makes every category ambiguous.
6. Breaking the supply chain. Common faults: a publisher.id that differs from the last node's sid, complete set to 1 when a reseller is missing, or a node whose asi publishes no sellers.json entry for the sid.
7. Sending gpp without gpp_sid, or the reverse. The string alone does not say which section governs this transaction.
8. Reading deprecated fields. Video.placement gave way to plcmt in 2.6-202303, Video.sequence to slotinpod, and Bid.api to apis. Read both during migration, write only the new ones.
9. Rejecting unknown fields. Since 2.6-202211 the versioning policy requires partners to ignore fields and values they do not recognise. A strict schema validator that drops the request breaks this rule.
10. Doing money in floating point. The spec recommends integer or decimal maths, such as BigDecimal in Java, for prices (OpenRTB 2.6, Object: Bid).

To check your own payloads against these rules, paste them into the OpenRTB bid request builder and validator. The RTB architecture hub collects the related engineering pages.

1. IAB Tech Lab, "OpenRTB API Specification Version 2.6" (2.6.md, main branch, accessed 9 November 2026). https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/2.6.md
2. IAB Tech Lab, "OpenRTB 2.x Implementation Notes" (implementation.md, accessed 9 November 2026). https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md
3. IAB Tech Lab, openrtb2.x releases, 2.6-202210 (3 November 2022) to 2.6-202606 (11 June 2026), accessed 9 November 2026. https://github.com/InteractiveAdvertisingBureau/openrtb2.x/releases
4. IAB Tech Lab, "AdCOM Specification v1.0" (accessed 9 November 2026). https://github.com/InteractiveAdvertisingBureau/AdCOM/blob/main/AdCOM%20v1.0%20FINAL.md
5. IAB Tech Lab, "OpenRTB Specification v3.0" (lists of no-bid and loss reason codes). https://github.com/InteractiveAdvertisingBureau/openrtb/blob/master/OpenRTB%20v3.0%20FINAL.md
6. IAB Tech Lab, "Global Privacy Platform: Consent String Specification" (accessed 9 November 2026). https://github.com/InteractiveAdvertisingBureau/Global-Privacy-Platform/blob/main/Core/Consent%20String%20Specification.md
7. IAB Tech Lab, "GPP Section Information" (accessed 9 November 2026). https://github.com/InteractiveAdvertisingBureau/Global-Privacy-Platform/blob/main/Sections/Section%20Information.md
8. IAB Tech Lab, Global Privacy Platform repository, commit "Prepare to finalize" to the MSPA US National section (4 November 2026). https://github.com/InteractiveAdvertisingBureau/Global-Privacy-Platform/commit/ab767c179195da2c33c89832ef7123d76fc3008a
9. IAB Europe and IAB Tech Lab, "TCF: Consent string and vendor list formats v2" (revision 2.3, April 2025; accessed 9 November 2026). https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/blob/master/TCFv2/IAB%20Tech%20Lab%20-%20Consent%20string%20and%20vendor%20list%20formats%20v2.md
10. IAB Tech Lab, Taxonomies repository: Content Taxonomy 3.1, Ad Product Taxonomy 2.0, CTV Genre Mapping (accessed 9 November 2026). https://github.com/InteractiveAdvertisingBureau/Taxonomies