A Practical OpenRTB 2.6 Supply-Chain Integration Checklist for DOOH (2026 Edition)

**TL;DR:** Between January 1 – May 11, 2026, network telemetry processed billions of bid requests across a supply chain routing through 100 distinct SSP nodes to 200 active DSP integrations. Median bid response latency sits at 180ms, with p95 at 350ms. To capture yield in this environment, DSPs must enforce strict compliance with OpenRTB 2.6 DOOH extensions. This tactical runbook details the 14 engineering checks required to validate payloads, optimize timeout budgets (600ms absolute maximum), and parse impression multipliers without triggering silent auction failures.

## Check 1 of 14: Validating `source.ext.schain` Integrity

**What to verify and why it matters:** OpenRTB 2.6 mandates strict tracking of the inventory's path to market via the SupplyChain object. With up to 100 SSPs participating in upstream and downstream routing, integration engineers must verify that their bidding systems can ingest, parse, and validate the `schain` object. Dropping or misinterpreting this object breaks transparency and often violates DSP-side compliance rules designed to prevent unauthorized reselling. You can review the exact specifications in the [IAB OpenRTB 2.6 PDF](https://www.iab.com/wp-content/uploads/2025/01/IAB_OpenRTB-2.6_FINAL.pdf).

**JSON Field Paths:** Inspect `bid_request.source.ext.schain`. Ensure your parser correctly extracts `schain.ver`, `schain.complete`, and iterates through the `schain.nodes` array. Specifically, extract `nodes[].asi` (Advertising System Identifier) and `nodes[].sid` (Seller ID).

**Failure-Mode:** If the DSP fails to parse the `schain` array, or rejects requests where `schain.complete` equals `0` (indicating an incomplete chain but valid partial path), the bidder will silently drop legitimate inventory. This results in zero bids submitted for highly desirable programmatic DOOH placements.

**Canonical Fix:** Update the DSP ingestion layer to recursively parse the `nodes` array. Validate the `asi` against known programmatic exchanges and ensure that the `sid` maps correctly to upstream publisher definitions. Do not automatically reject `complete: 0` unless strict direct-only buying rules are enforced at the campaign level.

## Check 2 of 14: Cross-Referencing Publisher IDs with `sellers.json`

**What to verify and why it matters:** Supply chain validation requires mapping the publisher ID in the bid request back to a centralized `sellers.json` file. This prevents spoofing and ensures the DSP is buying from an authorized seller node. Standardized by the IAB Tech Lab, [Sellers.json](https://iabtechlab.com/standards/sellers-json/) is the definitive source of truth for seller identities.

**JSON Field Paths:** Extract `bid_request.app.publisher.id` or `bid_request.site.publisher.id`. Cross-reference this string against the `seller_id` field in the SSP's hosted `sellers.json` file.

**Failure-Mode:** Misclassification occurs when a DSP expects a `site` object but receives an `app` object (common in DOOH, where digital screens are often modeled as applications). If the DSP's crawler fails to map `app.publisher.id` to the `seller_id`, the inventory is flagged as unauthorized or "domain unverified," leading to instant bid rejection.

**Canonical Fix:** Configure the DSP's pre-bid validation logic to accept both `app.publisher.id` and `site.publisher.id` as valid keys for `sellers.json` lookups. Cache the `sellers.json` file frequently (every 12-24 hours) to ensure newly onboarded publishers are recognized instantly without triggering false-positive blockages.

## Check 3 of 14: Parsing DOOH-Specific Extensions in `imp[0].ext.dooh`

**What to verify and why it matters:** OpenRTB 2.6 introduced standardized extensions specifically for Digital Out-of-Home. These extensions carry critical context about the physical environment of the screen, such as venue type, screen orientation, and taxonomy. Understanding this context is essential for targeting logic, as detailed in our [programmatic-dooh-101](/guides/programmatic-dooh-101/) documentation.

**JSON Field Paths:** Inspect `bid_request.imp[0].ext.dooh`. Key fields include `venue.tax` (taxonomy, typically set to `2` for DPAA), `venue.types` (array of integers representing venue categories like malls or gyms), and `multiplier`.

**Failure-Mode:** A DSP that ignores `ext.dooh` will treat the request as a generic mobile or desktop impression. This strips away targeting capabilities, meaning advertisers cannot restrict their campaigns to specific physical environments. The bidder might also fail to recognize the request as DOOH entirely, applying invalid web-centric viewability metrics.

**Canonical Fix:** Implement a dedicated parsing module for `imp[0].ext.dooh`. Map the `venue.types` integers to your DSP's internal physical targeting categories. Ensure your UI allows buyers to target these specific integer arrays to unlock contextual DOOH buying across 15,400 screens without relying on reverse-IP lookups.

## Check 4 of 14: Processing Impression Multipliers via `imp[0].qty.multiplier`

**What to verify and why it matters:** Unlike personal devices, a single DOOH screen is viewed by multiple people simultaneously. The impression multiplier quantifies this audience. In OpenRTB 2.6, this is formally handled via the quantity object, moving away from legacy custom extensions.

**JSON Field Paths:** Inspect `bid_request.imp[0].qty.multiplier`. In older or transitional implementations, you may also need to check `bid_request.imp[0].ext.dooh.multiplier` as a fallback.

**Failure-Mode:** If a DSP bids a $14.50 CPM on a request with a multiplier of 10.5, but fails to parse the multiplier, it assumes it is buying a single impression. The SSP will clear the bid and charge the DSP for 10.5 impressions, resulting in a massive budget overrun and a pacing failure on the DSP side.

**Canonical Fix:** The DSP must extract `imp[0].qty.multiplier`. The internal pacing and bidding engine must multiply the base CPM by this float value to calculate the true cost of the playout. Both the bid response and the internal reporting database must natively support fractional impressions.

## Check 5 of 14: Timeout Budgets and `tmax` Enforcement

**What to verify and why it matters:** Programmatic DOOH operates on strict playout schedules. If a bid response arrives too late, the screen has already moved to the next slot. Network telemetry between January 1 – May 11, 2026, shows a median bid response latency of 180ms, with a p95 of 350ms. The absolute maximum timeout budget allowed before the SSP drops the connection is 600ms.

**JSON Field Paths:** Inspect `bid_request.tmax`. This integer defines the maximum amount of time (in milliseconds) the DSP has to process the request and return a valid HTTP 200 response.

**Failure-Mode:** DSPs with heavy internal processing (e.g., complex fraud scanning or unoptimized database queries) frequently exceed the `tmax` value. If a DSP consistently responds in 650ms, 100% of its bids will be discarded by the SSP, resulting in zero win notifications and stalled campaigns.

**Canonical Fix:** Extract the `tmax` value dynamically per request. Subtract a safety margin for network transit time (typically 30-50ms). Set this calculated value as the hard timeout for all internal DSP microservices. If internal decisioning exceeds this threshold, return an HTTP 204 No Content immediately rather than a late bid.

## Check 6 of 14: Geospatial Precision in `device.geo` vs `imp[0].ext.dooh.venue`

**What to verify and why it matters:** Accurate geospatial data is the bedrock of DOOH targeting. DSPs must distinguish between the IP address of the media player (which might route through a centralized data center) and the actual physical latitude/longitude of the screen.

**JSON Field Paths:** Inspect `bid_request.device.geo.lat` and `bid_request.device.geo.lon`. Additionally, verify `bid_request.device.geo.type` (value `1` indicates GPS, `2` indicates IP derivation).

**Failure-Mode:** If the DSP relies solely on IP-based geolocation, a screen located in Chicago might be incorrectly mapped to a data center in Ashburn, Virginia. This completely breaks proximity targeting, delivering irrelevant ads to the wrong physical audience.

**Canonical Fix:** Prioritize the exact `lat` and `lon` coordinates provided in `device.geo`. Verify that `type` equals `1`. If the coordinates are present, bypass any internal IP-to-Geo lookup services. Treat the provided coordinates as the absolute source of truth for the physical location of the screen.

## Check 7 of 14: Video Placement Signaling in `imp[0].video.plcmt`

**What to verify and why it matters:** OpenRTB 2.6 deprecated the legacy `placement` field in favor of the more precise `plcmt` attribute. This integer defines the exact nature of the video inventory, which is critical for determining whether a DOOH screen supports full-motion video or just static imagery.

**JSON Field Paths:** Inspect `bid_request.imp[0].video.plcmt`. Valid values range from 1 to 4, with `4` (Standalone) being the most common classification for full-screen DOOH video takeovers.

**Failure-Mode:** If a DSP still relies on the deprecated `placement` field, it will fail to classify the video inventory correctly. This often triggers internal viewability filters that reject the bid request, assuming the inventory is non-compliant outstream video rather than premium DOOH.

**Canonical Fix:** Update the video parsing logic to read `imp[0].video.plcmt`. Map value `4` to your internal "in-stream/standalone" category to ensure premium DOOH video inventory passes all pre-bid quality filters. Ensure fallback logic exists if `plcmt` is absent but legacy `placement` is present.

## Check 8 of 14: Floor Price Resolution and Currency in `imp[0].bidfloor`

**What to verify and why it matters:** DOOH inventory often carries high floor prices due to the one-to-many nature of the medium. DSPs must correctly parse the floor price and the associated currency to avoid submitting invalid bids that are mathematically guaranteed to lose.

**JSON Field Paths:** Inspect `bid_request.imp[0].bidfloor` (float) and `bid_request.imp[0].bidfloorcur` (string). Also inspect the top-level `bid_request.cur` array to determine which currencies the SSP accepts in the response.

**Failure-Mode:** A DSP receives a request with a $12.50 CPM floor priced in EUR. The DSP ignores the currency field, internalizes the floor as $12.50 USD, and bids $13.00 USD. Because $13.00 USD is lower than €12.50 EUR, the bid is rejected by the SSP for failing to clear the floor.

**Canonical Fix:** Implement real-time currency conversion at the edge. Extract `bidfloorcur` and convert the `bidfloor` float into the DSP's native bidding currency using daily updated FX rates. Ensure the final bid price submitted in the response matches one of the accepted currencies listed in the `cur` array.

## Check 9 of 14: Blocklist Enforcement via `bcat`, `badv`, and `bapp`

**What to verify and why it matters:** DOOH publishers enforce strict creative blocklists. A screen located near a school will explicitly block alcohol, gambling, and mature content. Adhering to these blocklists is mandatory; failing to do so damages publisher trust and lowers overall win rates, as detailed in our [fill-rates](/research/state-of-dooh-2026/fill-rates/) analysis.

**JSON Field Paths:** Inspect the top-level arrays `bid_request.bcat` (blocked IAB categories), `bid_request.badv` (blocked advertiser domains), and `bid_request.bapp` (blocked applications).

**Failure-Mode:** The DSP ignores the `bcat` array and submits a bid for a spirits brand on a screen that explicitly blocks the IAB category for alcohol. The SSP's creative audit system flags the violation, blocks the bid, and potentially penalizes the DSP's future throttle rate. When blocklists are respected, DSPs routinely see an 82% fill rate on submitted valid bids.

**Canonical Fix:** Ingest the `bcat` and `badv` arrays. Before running the internal auction, filter out any eligible campaigns whose assigned IAB categories or landing page domains intersect with the blocked arrays. Only submit bids for creatives that are explicitly clear of all blocklist constraints.

## Check 10 of 14: Private Marketplace Deal Mapping in `imp[0].pmp.deals`

**What to verify and why it matters:** A significant volume of premium DOOH inventory is transacted via Private Marketplaces (PMPs). DSPs must correctly identify when an impression is part of a negotiated deal and prioritize that deal logic over open-market bidding.

**JSON Field Paths:** Inspect `bid_request.imp[0].pmp.deals`. Iterate through the array and extract `deals[].id` (the Deal ID) and `deals[].bidfloor`.

**Failure-Mode:** If the DSP fails to parse the `pmp.deals` array, it treats the request as open market. It may bid below the negotiated deal floor or fail to attach the Deal ID to the bid response. The SSP rejects the bid, and the advertiser fails to deliver on their negotiated 10,200 impressions contract.

**Canonical Fix:** Prioritize PMP logic. If the `pmp.deals` array is present, check the `deals[].id` against active campaigns in the DSP. If a match is found, the DSP must include the exact Deal ID in the bid response (`seatbid[0].bid[0].dealid`) and ensure the bid price meets or exceeds the specific `deals[].bidfloor`, overriding the generic open-market floor.

## Check 11 of 14: Creative Markup Validation in `seatbid[0].bid[0].adm`

**What to verify and why it matters:** DOOH screens have rigid creative requirements. They typically accept either a raw VAST XML payload for video or a direct URL to a static image. Sending the wrong markup format results in a blank screen and a forfeited impression. For deeper specifications, consult the [dsp-api](/support/developers/dsp-api/) documentation.

**JSON Field Paths:** When constructing the bid response, populate `seatbid[0].bid[0].adm`. The payload must strictly conform to the formats requested in `imp[0].video` or `imp[0].banner`.

**Failure-Mode:** The bid request specifies `imp[0].banner` with specific width and height requirements for a static JPEG. The DSP responds with a VAST XML payload wrapped in an HTML iframe. The DOOH media player cannot render HTML iframes, resulting in a playback error and zero billed impressions.

**Canonical Fix:** Implement strict payload validation before generating the `adm` string. If the request demands video, return pure VAST XML. If the request demands a banner, return the direct image URL or the exact image markup requested. Never wrap DOOH creatives in generic web-centric HTML wrappers.

## Check 12 of 14: Billing vs. Notice URL Disambiguation (`burl` vs `nurl`)

**What to verify and why it matters:** In OpenRTB 2.6, the distinction between the Billing URL (`burl`) and the Notice URL (`nurl`) is critical, especially in DOOH where playout confirmation is delayed. The `burl` is fired only when the ad actually renders on the physical screen, while the `nurl` merely indicates the DSP won the auction. The [OpenRTB GitHub](https://github.com/InteractiveAdvertisingBureau/openrtb) outlines these event semantics clearly.

**JSON Field Paths:** In the bid response, populate `seatbid[0].bid[0].burl` for actual impression counting and billing, and `seatbid[0].bid[0].nurl` for auction win notification.

**Failure-Mode:** A DSP counts an impression and deducts advertiser budget as soon as the `nurl` fires. However, the media player loses internet connectivity before the ad plays, meaning the `burl` never fires. The DSP has now billed the advertiser for an ad that never physically rendered on the screen.

**Canonical Fix:** Decouple auction wins from financial billing. Use the `nurl` purely for internal pacing and win-rate analytics. Only deduct advertiser budget and record a true impression when the `burl` is fired by the SSP, confirming physical playout on the screen.

## Check 13 of 14: Creative ID Propagation via `seatbid[0].bid[0].crid`

**What to verify and why it matters:** DOOH inventory owners manually audit and approve creatives before they are allowed to display across 4,200 venues. This approval workflow relies entirely on the Creative ID (`crid`) remaining static and consistent for a given media asset.

**JSON Field Paths:** In the bid response, ensure `seatbid[0].bid[0].crid` is populated with a unique, persistent string that maps exactly to the submitted creative asset.

**Failure-Mode:** The DSP dynamically generates a new `crid` every time it bids, even if the underlying video file is the same. The SSP's creative audit system sees thousands of "new" creatives, overwhelming the manual approval queue. The bids are continuously rejected because the dynamically generated `crid` is marked as "pending approval."

**Canonical Fix:** Generate a deterministic hash (e.g., MD5 or SHA-256) of the actual creative asset file. Use this hash as the persistent `crid`. This ensures that once a specific video or image is approved by the publisher, all subsequent bids using that asset will instantly clear the audit gates.

## Check 14 of 14: Handling Multi-SSP Routing and Waterfall Deduplication

**What to verify and why it matters:** The modern programmatic landscape is highly interconnected. A single DOOH screen might route its inventory through multiple SSPs simultaneously. With 200 DSPs active in the demand waterfall, DSPs must deduplicate bid requests to avoid bidding against themselves and artificially inflating the clearing price, a dynamic explored in our [demand-ecosystem](/research/state-of-dooh-2026/demand-ecosystem/) report.

**JSON Field Paths:** Inspect `bid_request.source.tid` (Transaction ID) and `bid_request.item.id`.

**Failure-Mode:** A DSP receives the exact same impression opportunity from three different SSP integrations. It processes all three independently, submitting three bids. The DSP ends up competing against its own campaigns, driving up the CPM unnecessarily and wasting internal compute resources.

**Canonical Fix:** Implement a real-time deduplication cache at the edge layer. Use the `source.tid` as the primary key. If multiple requests arrive with the same `tid` within a 500ms window, identify them as duplicates. Select the optimal supply path (based on historical win rates or lower take-rates) and submit a single bid, discarding the redundant requests.

## FAQ

### What is the maximum acceptable latency for a bid response in this environment?

The absolute maximum recommended timeout is 600ms. However, network telemetry indicates that the median bid response latency is 180ms, with a p95 of 350ms. To maintain healthy win rates and avoid silent auction drops, DSPs should aim to return payloads well within the 350ms threshold, accounting for network transit times.

### How should a DSP handle a bid request missing the `imp[0].ext.dooh` object?

If the `ext.dooh` object is missing, the DSP should fall back to standard OpenRTB parsing. However, for campaigns strictly targeting DOOH environments, the absence of this object usually means the inventory lacks the necessary contextual signals (like venue type or multiplier). In strict DOOH-only setups, these requests should be skipped to prevent buying generic web/mobile inventory by mistake.

### Why is my DSP receiving win notifications but no impressions are being logged?

This is almost always a failure to disambiguate the Notice URL (`nurl`) from the Billing URL (`burl`). In DOOH, a win notification (`nurl`) simply means you won the auction, but the actual playout on the screen may be delayed or interrupted. Impressions and billing must only be triggered when the `burl` fires, confirming that the creative physically rendered on the screen.