OpenRTB 2.6 Bid Request Reference
The objects that make up a bid request, with their fields, types and requirement levels — and, separately, what each one actually means when something is not working. Field data comes from the IAB Tech Lab specification; the practitioner notes are marked as such.
A bid request carries exactly one of site, app or dooh — never two. Integrations that read site unconditionally simply find nothing on in-app traffic, which is one of the more common causes of an inventory type appearing to be missing entirely.
Objects
- (root)BidRequestThe top-level container for an auction. Carries the impressions on offer plus everything the bidder needs to value them.
- BidRequest.imp[]ImpOne ad placement being auctioned. A request can carry several, and each is bid on independently.
- BidRequest.imp[].bannerBannerA display placement — static images, expandables, or in-banner video.
- BidRequest.imp[].videoVideoA video placement, generally expecting a VAST response. The most option-heavy object in the protocol.
- BidRequest.deviceDeviceThe end user's hardware, platform, connection and advertising identifier.
- BidRequest.device.geoGeoLocation, either as coordinates or as administrative codes, with a field saying where the data came from.
- BidRequest.userUserThe human behind the request: identifiers, audience segments and consent.
- BidRequest.sourceSourceWho is selling this impression and through which chain of intermediaries.
- BidRequest.regsRegsWhich privacy regulations apply to this request, and the consent signals that go with them.
Required does not mean sufficient
The specification's required fields are the minimum for the protocol to function technically, not the minimum for anyone to want to bid. A request carrying only an id and a bare imp is perfectly valid and will be ignored by essentially every buyer, because there is nothing in it to value — no domain, no device, no geo, no floor. The fields marked recommended are where the commercial requirements live, and thin requests are one of the quieter reasons a supply integration underperforms.
The spec is also explicit that implementations must tolerate unexpected fields rather than rejecting them. Since 2.6-202211 the version number only increments on breaking changes, so additive updates arrive continuously under the same 2.6 label — a parser that rejects unknown fields will break on a perfectly conformant request at some point.