Advertisers · DSP partners

The specification, for integration engineers.

This page is written for the engineer who will wire the seat, not for the media plan. Protocol, request structure, transparency fields, deal mechanics, scoping and the integration process, in one place.

OpenRTB 2.6JSON over HTTPSschain on every requestSandbox access
OPENRTB 2.6
POST /rtb/bid HTTP/2
{ "app": { "bundle": "com.example.app" },
"source": { "schain": { "complete": 1, "nodes": [...] } } }
200 OK · response parsed

Per-seat endpoints · sandbox first

01 · Protocol

OpenRTB 2.6 over HTTPS.

AspectSpecification
Protocol versionOpenRTB 2.6, JSON serialization over HTTPS POST
EndpointsPer-seat endpoints issued at provisioning; one sandbox, one production
SerializationJSON; protobuf is supported where agreed during integration
TransportHTTPS with keep-alive; gzip request bodies accepted
TimeoutsBid response deadlines are set per impression type and shared at provisioning, with CTV pod deadlines distinct from mobile
Consent signalsTCF v2.2 and GPP strings passed in the request; enforcement applied before the request is sent
02 · Bid request detail

What arrives on every request.

In-app

The app object

Declared bundle ID, store URL, app name and category, checked against the store listing before the app is allowed to monetize. Publisher and account identifiers match the seller registry behind our supply.

CTV

The content object

Content series, genre and season or episode identifiers where the platform provides them, plus pod position and slot in the pod via the OpenRTB 2.6 imp fields, so bidders price position honestly.

Impressions

Impression types

Interstitial, rewarded, banner, native, playable and offerwall on mobile; pre-roll, mid-roll, post-roll and pause on CTV. Video protocols VAST, with client-side and server-side variants declared per impression.

03 · Supply transparency and deals

Every request carries its provenance.

Deals

Open auction

All eligible impressions, cleared on price. Floors and category screens apply before your seat sees the request.

Deals

PMP and PG mechanics

PMP impressions carry the deal ID with a deal floor; programmatic guaranteed commitments arrive as pre-committed impressions with pacing owned by the platform. Deal IDs are assigned at setup and trafficked in the console.

Verification

What mismatches mean

If the schain does not resolve to an authorized path, the request does not reach you. That filtering is the enforcement of the authorized-sellers-only policy on our supply.

Scoping and the integration process

01

Scope the seat

Query volume, queries per second (QPS), is managed with filters: geography, platform, format, content category and deal membership. Scope changes are applied at the seat without re-integration.

02

Sandbox

Sandbox endpoints return synthetic requests covering every impression type, including CTV pod structures, so parsers are built against real shapes.

03

Test traffic

Live test traffic runs at agreed QPS; response times are measured against the deadline budgets shared at provisioning.

04

Go live

Production endpoints issue after test acceptance: parsing complete, response times inside budget, deals trafficked. Ramp is scheduled, not flipped.

REPORTING

What you receive back

Win and loss reasons per auction, spend by deal and impression type, and settlement reporting that reconciles to your console. Creative status and review state come from the demand console, including rejection reasons when policy review fails a creative.

Loss reasonsSpend by dealReconciled settlement
ARTIFACTS

Verify us first

Read the seller registry behind every account ID, ours included, then read the schain node on real test traffic before production ramps.

Demand integration

Wire the seat. Verify everything.

Send your OpenRTB capabilities and target QPS. The integration team provisions sandbox access and the scoping call.

OpenRTB 2.6 · JSON · schain · sandbox first