Bid Request
A bid request is the structured message an ad exchange sends out the instant an ad slot becomes available, describing the impression so buyers can decide what to bid.

A bid request is the structured message an ad exchange or supply-side platform sends out the instant an ad slot becomes available, describing the impression, the page or app context, and whatever's known about the user and device, so potential buyers can decide whether to bid and how much.
What's inside a bid request#
Under the OpenRTB protocol that most of the industry standardizes on, a bid request is a JSON object carrying a fairly consistent set of fields: an impression object describing the ad slot's size and format, publisher and site or app ID, geo-targeting data like country and region, device type and connection info, and any user or first-party data the seller is permitted to share. If the impression is part of a negotiated arrangement, the request also carries a deal identifier referencing that specific deal.
Every demand-side platform connected to that exchange receives the same request simultaneously, over what's typically a strict response window measured in milliseconds. Each DSP's bidding logic evaluates it against active campaigns and either returns a bid response with a price and creative, or declines to bid at all.
Why bid requests matter to buyers#
The quality and completeness of a bid request directly shapes what a DSP can do with it. A request with rich contextual targeting signals and clean site or app identification lets a buyer's algorithm make a genuinely informed decision. A sparse or poorly labeled request, missing app-ads.txt verification or an incomplete supply chain object, gives the DSP less to work with, and cautious buyers often bid conservatively or skip those requests entirely rather than bid blind.
This is also where fraud gets filtered out or slips through. A bid request claiming to represent a premium publisher's inventory, without the accompanying ads.txt or sellers.json records to back that claim, is exactly the kind of signal DSPs and buyers use to reject spoofed or misrepresented inventory before ever bidding on it.
Reading bid request volume as a market signal#
Buyers rarely see individual bid requests directly, but the aggregate pattern, how many requests a given placement or geo generates, and how that compares against actual bid responses, is a useful proxy for real market demand. For competitive research rather than raw auction logs, seeing what creatives and advertisers are actually winning and running live across networks tells you more about the market than bid volume alone. OpenAdLibrary's ad intelligence index is built for exactly that: live creative-level visibility instead of inferring the market from auction plumbing.
FAQ#
Does every DSP see the same bid request?
Within a single auction round, yes, connected DSPs typically receive the same request simultaneously. What differs is how each DSP's own logic decides whether and how much to bid on it.
How fast does a DSP have to respond to a bid request?
Response windows are usually measured in tens to low hundreds of milliseconds, tight enough that a DSP failing to respond in time is simply treated as a no-bid for that impression.
Is user data always included in a bid request?
No. What's included depends on consent, regulation, and what the publisher and its SSP are configured to pass along. Many requests today carry less individual-level user data than they used to, leaning more on contextual and first-party signals instead.
What happens if a bid request is missing supply chain data?
Buyers and their fraud-detection tooling often treat incomplete supply chain or ads.txt data as a risk signal. Some DSPs will still bid but more conservatively, while others are configured to skip those requests outright.



