Testing

The sandbox speaks the same protocol as production, answers with test bids, and never bills. Work through it before your integration engineer enables production traffic.

Sandbox host

HTTP

POST /v1/auction/{endpoint_key} HTTP/1.1
Host: sandbox.rtb.adon3-ads.com
Content-Type: application/json; charset=utf-8
x-openrtb-version: 2.6

Sandbox credentials come with your production ones. Sandbox differs in three ways:

Bids come back on nearly every valid request, so you can exercise the render path without waiting for real demand
Wins are never billed, and nothing reaches reporting
Bodies are retained for 30 days rather than 7

Everything else behaves as production does. Validation, error codes, macro substitution and response shape are identical, so a request that passes sandbox validation passes production validation.

Sample bodies

Shell

# Fetch a sample request
curl -sS https://sandbox.rtb.adon3-ads.com/v1/samples/banner.json -o sample-banner.json

# Post it at the sandbox
curl -sS -X POST 'https://sandbox.rtb.adon3-ads.com/v1/auction/ek_31c9b7e2a04d' \
  -H 'Content-Type: application/json; charset=utf-8' \
  -H 'x-openrtb-version: 2.6' \
  --data-binary @sample-banner.json

Samples are available for banner.json, video.json, audio.json, native.json, app-banner.json and pmp-deal.json. They match the bodies on Bid Request Samples, so you can diff your own request against one to find what you are missing.

Go-live checklist

Your integration engineer walks through this with you before production is enabled.

The request

x-openrtb-version is sent, and matches the version you actually build
id is unique per auction, not per session or per page
device.ua is present and unmodified
device.ip or device.ipv6 carries the visitor's address, not your server's
site.domain or app.bundle is present and correct
Exactly one entry in imp, carrying exactly one of the four format objects
source.schain resolves against your published sellers.json
imp.bidfloor and bidfloorcur reflect the floor you actually enforce

The response

204 is handled as a normal outcome, not logged as an error
200 bodies are parsed, and bid.impid is checked against imp.id
dealid is checked before a deal impression is counted
Creative size is checked against w and h when they are returned

Macros and notices

No literal ${ remains in rendered markup or in a fired notice
nurl fires on the win
burl fires when the impression is counted, and is not skipped
Revenue is reconciled against the substituted ${AUCTION_PRICE}, not bid.price

Reporting

A report call succeeds with your sspId and auth
Your own impression counts are compared against impressions for one full day

The two that fail most often are burl never firing, and macro substitution being applied to the notices but not to the markup.

Verifying your supply chain

Confirm the chain resolves before the go-live call rather than during it:

Shell

curl -sS https://example-ssp.com/sellers.json | head -40

Each schain node's asi and sid must appear in the sellers.json at that asi domain. Chains that do not resolve are rejected with SCHAIN_INVALID before reaching any bidder, so no amount of request-side work will fix them.

Debugging live traffic

Once you are live, reporting gives you daily requests, responses, impressions, clicks and revenue. For anything those figures do not explain, send the integration office the BidRequest.id of an affected auction. We retain full bodies for seven days and can replay any auction with the exact bodies both sides exchanged, which resolves most questions in one round trip.