An OpenRTB bid request is a structured message describing an eligible advertising opportunity. It can include impression, site or app, device, user, deal and supply-chain information, depending on the specification version, privacy rules and seller implementation.
Key takeaways
- A bid request describes an opportunity; it does not guarantee every field is present.
- The impression object defines the media opportunity and compatible format details.
- Site, app and device objects describe delivery context when available.
- Buyers should validate fields, privacy signals and extensions instead of assuming universal support.
What a bid request represents
In an OpenRTB workflow, the seller sends a structured message describing an impression opportunity. A buyer uses that message to decide whether the opportunity matches an eligible campaign and, if so, what bid and creative response to return.
The request is not a promise that every possible OpenRTB field exists. Implementations vary by specification version, media type, privacy requirements and platform capability.
The impression object
The impression object identifies the auctionable opportunity. Depending on the format, it can carry banner, video, native or other supported media information. It can also include identifiers, bid-floor data, deal references and placement-related signals.
Site or app context
A request may describe the website or application where the impression is available. Buyers use this context for eligibility, quality, category or campaign decisions. Missing or inconsistent domain and app information should be handled cautiously rather than silently inferred.
Device and connection context
Device-related fields can describe browser, operating system, device type, language, IP-derived context or connection details when permitted. These signals can help with creative compatibility and targeting, but they also interact with privacy and consent requirements.
User and privacy signals
User-related data should only be processed when the signal is present, permitted and meaningful for the transaction. Buyers need to respect applicable consent, privacy and platform policies instead of treating identity fields as universally available.
Deals and supply-chain information
OpenRTB can carry deal information for private marketplace or preferred buying workflows. Supply-chain transparency signals can help buyers understand intermediaries and the path to inventory. These fields complement standards such as ads.txt and sellers.json rather than replacing broader quality controls.
What a buyer should validate
- Request and impression identifiers are present and usable.
- The media type matches an eligible campaign and creative.
- Pricing and currency fields are interpreted correctly.
- Privacy and consent signals are respected.
- Supply, domain or app information passes quality policy.
- Extensions are processed only when the integration supports them.
From request to response
After evaluation, the buyer can return a bid response containing a price and compatible creative information, or it can decline. The seller then validates eligible responses and applies auction rules before delivery.
Frequently asked questions
Does every OpenRTB bid request contain the same fields?
No. Field availability varies by version, media type, seller implementation, privacy requirements and the underlying inventory.
Is a bid floor always present?
No. A seller can provide floor information, but buyers should not assume every request contains the same pricing fields.
Can a buyer trust every field without validation?
No. Production integrations should validate field formats, supported extensions, privacy signals and supply quality before using the data.