Multi-format RTB exchange · rtb.adbustr.com
Adbustr Exchange is our own programmatic stack — supply endpoints, internal auction, creative rendering, tracking and reporting, written by our engineering team and served from a single Go core. Video, VPAID, banner, ADM, popunder and in-app inventory trade through one OpenRTB 2.5 contract, with a SupplyChain object on every request and impression-level logging on every render.
Standards the exchange speaks
One OpenRTB 2.5 wire contract inbound and outbound, a SupplyChain object on every request, and seller declarations served at their canonical locations. See Transparency for the full list.
The inefficiency
The long tail of video player environments — IPTV operators, OTT streaming applications, FAST channels, smart TV apps, set-top box ecosystems, mobile video players — does not speak one protocol. One publisher needs a VAST tag, the next a VPAID media file, the next a JSON feed for a popunder script, the next an in-app SDK. Every one of those integrations is a separate engineering project, so the inventory ends up resold down a chain of intermediaries: priced low, sold blind, several hops away from the buyer.
Each hop costs margin and information. By the time a bid request reaches demand, the buyer no longer knows which publisher it came from, and the publisher no longer knows which bid cleared, at what price, or why the others declined.
Adbustr closes that distance. We wrote the exchange ourselves — the supply endpoints, the auction, the renderer, the tracking layer — so a publisher integrates once in the format their player already speaks, and the request goes straight into an auction whose entire path is declared. One hop between supply and demand, and a log line for every request on both sides of it.
Player environments we integrate · and what each one speaks
Eight entry points, one auction: VAST 3.0 tags and wrappers, banner HTML, VPAID, ADM JSON, popunder feeds, our in-app SDK, and an OpenRTB 2.5 server-to-server endpoint. Whatever the player speaks, we normalise it into one canonical bid request.
Every eligible DSP receives the same request at the same moment, inside tmax. Second price by default, ranked by price × currency rate × BidRate, floors and bid rates configured per zone and per partner.
SupplyChain object on every outgoing request, published sellers.json, ads.txt and app-ads.txt, and a per-request log with the verdict — bid or no-bid, and the reason.
Built for three sides of the exchange
The engine
Resonance is our decisioning layer, written in Go and logged to ClickHouse. It enriches each incoming request with GeoIP and browser data, screens it against the inbound quality filters, selects the demand partners eligible by geo, device type and publisher list, then fans the canonical OpenRTB 2.5 request out to all of them in parallel within tmax. Returning bids are normalised by currency rate and bid rate; anything below the floor, malformed or late is dropped before clearing.
Auction window (tmax)
Supply entry points
Creative formats served
We are the exchange, not a reseller of one — so the path from publisher to DSP has a single node in it, and that node is us. A SupplyChain object travels with every outgoing request, seller and app declarations are served at their canonical locations, and every impression, click and win notice is written to our own logs against the request that produced it. Partner numbers and our numbers reconcile line by line.
sellers.json is live. app-ads.txt is current. schain ships with every bid request.
Integrating supply, evaluating us as a demand partner, or reviewing the wire contract before you commit engineering time — you will be talking to the team that wrote the exchange, not to a reseller.