Partnership role
State whether you are bringing supply, demand or a two-way opportunity, which entity owns the connection and who supports it.
Endpoint readiness before endpoint exchange
AdSelect evaluates OpenRTB opportunities by aligning the business role, formats, environments, protocol details, request examples, expected scale, identity, supply-path information and reporting definitions before a controlled connection test.
Integration discovery
An endpoint alone does not establish technical or commercial fit. The first review should make the traffic, responsibility and measurement model understandable to both parties.
State whether you are bringing supply, demand or a two-way opportunity, which entity owns the connection and who supports it.
List CTV, in-app video, in-app banner or web display needs, plus the site, app or device context represented in requests.
Share the supported OpenRTB version, extensions, required fields, authentication approach, sample request and sample response.
Provide expected QPS, traffic distribution, timeout expectations, test limits and any ramp controls needed to protect both systems.
Identify sellers and inventory sources and provide ads.txt or app-ads.txt, sellers.json and SupplyChain information where applicable.
Align on time zone, currency where relevant, requests, bids, wins, impressions, errors, filtering and discrepancy contacts.
Request review
AdSelect does not publish a blanket promise that every OpenRTB object, version or extension is supported. The parties map the fields required for the exact environment and format before testing.
Site or app identity, publisher, content and placement information should match the inventory being represented.
Banner or video details, sizes, placement and creative constraints are reviewed against the opportunity.
Device, regulation, consent and user-related fields are handled only as supported and required for the integration.
Seller identity and SupplyChain information are checked for consistency with public transparency files where applicable.
Controlled connectivity
Each gate creates evidence for the next. Traffic should not scale because the endpoint returns a successful status code; it scales only after payload, delivery, quality and reporting are reviewed.
Agree versions, fields, formats, IDs, timeouts and response behavior.
Review sanitized request and response examples before live traffic.
Verify authentication, connectivity, parsing, timeouts and error handling.
Use agreed traffic limits, dates, monitoring and escalation contacts.
Compare delivery, quality and reporting before deciding on expansion.
Request, bid, win, impression and event counts can differ because systems measure at different points, use different time zones or apply different filtering. Partners document definitions, compare logs for an agreed period and escalate with examples rather than relying on a single aggregate total.
Live endpoints, credentials, partner IDs, tokens and unredacted request data are exchanged privately after fit is established. Public examples should be sanitized so they do not expose active systems or partner information.
Version and extension compatibility is confirmed for each opportunity during technical mapping. AdSelect does not publish a universal version claim before the specific integration requirements are reviewed.
Connection details are shared after the parties confirm roles, formats, environments, traffic expectations, request mapping, quality requirements and a controlled test scope.
No. Scale depends on continued technical stability, available inventory or demand, quality, reporting alignment and the results reviewed by both parties.
Share your role, formats, environments, markets, protocol details, expected QPS and a sanitized example. The AdSelect Team will prepare for the technical discussion.
Schedule an OpenRTB Call