The platform
Adbustr Exchange is a first-party programmatic stack: supply intake, decisioning, auction, rendering, anti-fraud and analytics, written by our engineering team and serving from rtb.adbustr.com. Not white-label, not resold. Below is what runs underneath.
Sign-up is three screens: email, password, code. The console opens immediately; traffic starts after review.
Resonance
An exchange is judged on one interval: the few hundred milliseconds between an ad request arriving and a cleared price leaving. Everything that decides the outcome (what the request is, whether it deserves demand, which partners see it, how the winner is priced) happens inside that interval, in one process.
Resonanceis that process. It is not a scoring service bolted onto someone else's stack: enrichment, quality filtering, demand selection, fan-out, clearing and settlement are stages of the same request path, and every stage records why it did what it did.
The exchange core is our own Go service, and the decisioning path runs inside the same process as the auction, with no network hop between the decision and the bid it governs.
Request path
01
A format handler parses the incoming call (sid, zone, page, creative dimensions), or accepts a ready OpenRTB 2.5 / 2.6 BidRequest on /rtb/{uid}. A GET on the OpenRTB endpoint is treated as a connectivity ping, not a bid request. Each endpoint carries its own live toggle, held in the Redis snapshot and fail-safe in the off position: requests are still accepted and logged, demand is simply not spent.
02
The request is resolved against real client IP, GeoIP (ISO2 country, region, city, coordinates) and browscap-derived browser, OS and device class. Missing asset data degrades the enrichment, never the request: the auction still runs on whatever signal is available.
03
We build one canonical OpenRTB 2.5 / 2.6 BidRequest: exactly one imp, a site or app object, device, user, source.ext.schain, regs.ext with GDPR and consent state, badv from the publisher-level advertiser blocklist, tmax, cur and at. The same wire contract runs inbound from supply and outbound to demand, so partners test one shape instead of per-publisher dialects.
04
Resonance, our decisioning layer, narrows the DSP set before a single byte leaves the box: active and public flags, per-DSP geo lists, device-type rules, zone-level white and black lists, and the buyeruid requirement for partners that only serve synced users. Per-partner request adaptations are applied on top, so a DSP with non-standard field expectations gets a request it can actually parse.
05
Every eligible DSP is queried concurrently inside tmax: 300 to 500 ms by default, configurable per publisher, zone and request, with a 500 ms per-DSP ceiling. Late responses are discarded rather than held. Each outcome is metered separately: request, bid, timeout, error, duration.
06
Bids are normalised to the base currency as Norm = price × currency rate × BidRate, then filtered: non-200 responses, empty bodies, unparseable JSON, price at or below zero, and anything under the applicable bidfloor are dropped. House campaigns are matched first and external demand competes right behind them, inside one real-time auction decided in tens of milliseconds, with the clearing price bounded below by the applicable bidfloor and above by the winner's own bid. The exact price paid on any given request is reported in the impression-level logs; partners reconcile against those logs rather than against a formula.
07
Price macros are substituted (AUCTION_PRICE, AUCTION_CURRENCY, AUCTION_ID and the rest), the winner nurl is called server-side, and every valid losing bid receives an lurl with a loss reason code. The burl travels inside the rendered creative and fires on the billable impression, not on the auction. For the OpenRTB channel the win notice can be proxied through /rtb/nurl/{id}, so the demand-side notice lands on the partner billable impression.
08
The winning creative leaves in whatever shape the supply point speaks: VAST 2 / 3 / 4 InLine or Wrapper via VASTAdTagURI, banner HTML, ADM JSON, popunder JSON or an in-app SDK response (SDK path in pilot). Partner media arriving in resale supply is wrapped and passed through unchanged. Our own impression and click pixels are injected at render time, so measurement does not depend on the buyer implementing anything.
Supply entry points
A publisher integrates the way its stack already works: a VAST tag, our 13.8 KB dependency-free player, an async banner tag, a JSON feed, a Prebid adapter, a server-to-server OpenRTB endpoint or the mobile SDK. Behind every one of them the same enrichment, fan-out and auction runs.
/vast/{type}GET · POSTVAST 2 / 3 / 4 XML · InLine or WrapperPublisher video players/wrapper/{uid}GETVAST wrapperPlayer redirect chains/rtb/{uid}GET · POSTOpenRTB 2.5 / 2.6 BidResponse · GET = pingServer-to-server supply partners/bn/getGETBanner HTML container and loader (async, IntersectionObserver, srcdoc sandbox)Display placements/bn/vpaidGETVAST wrapper around a partner-supplied VPAID media fileResale supply, pass-through only: we run no VPAID renderer/dsp/{pubid}GET · POSTADM · JSON with ready markupClient-side players/pop/{sid}GET · POSTJSON · url, price, cur, imp and click pixelsPopunder script/sdk/v1/adPOSTIn-app JSON · native assets, media URL, imageUnity and Android SDK (pilot, transacted as site inventory)/rtb/nurl/{id}GETWin-notice proxyDemand notices on the OpenRTB channelSupply is modelled as Publisher → Zone → per-DSP configuration. A zone carries its own format, DSP white and black lists, and per-partner overrides of bidfloor, BidRate and ReqFilter, either merging with or replacing the demand-side defaults.
One boundary worth stating plainly: VPAID is not a format we render. Partner media that arrives in resale supply is wrapped and passed through unchanged, and the exchange carries no VPAID renderer of its own.
Auction and economics
House campaigns and external demand run through the same real-time auction, ours first and the outside market right behind. Bids arrive in the partner currency and are normalised against the rate table held in Redis at bid time, before they are ranked. The clearing price is bounded below by the applicable floor and above by the winner's own bid, and the price recorded for each request is available to the partner in the impression-level logs. We hand over the log, not a formula.
Payout on a supply link is revenue multiplied by the revenue share for that country, falling back to the endpoint base rate when no country rule exists. The share is fixed at impression time, so a later report cannot rewrite what was already earned. Every one of these values is read from the database at serve time; none of them is compiled into the binary.
Configuration
The entire serving configuration (publishers, zones, demand feeds, OpenRTB endpoints, floors, bid rates, throttling, revenue share and currency rates) lives as a snapshot in Redis. Sync jobs project it from the source databases, bump config:version and publish config:reload; the serving process rereads the snapshot in place. No deploy, no restart, no dropped requests.
The same mechanism carries the live toggle on every OpenRTB endpoint. It is fail-safe in the off position: traffic keeps being accepted and logged while no demand is spent, which makes ramp-ups and incident containment a one-key flip rather than a release.
Sync jobs run inside the private network and talk only to our own database instance. The serving contour reaches no external hosts.
Traffic quality
Every inbound request runs nine realtime checks, among them bot user agents, datacenter IP and ASN ranges, geo mismatch, duplicate requests, rate limits, Tor exits and managed lists. Each endpoint runs them in shadow or in block mode, so a partner sees what would be cut before anything is cut.
device.ip and device.ua are mandatory, the user agent must resolve to our browser allow-list, and IAB25 / IAB25-3 / IAB26 categories are cut from site.cat and site.sectioncat when the mainstream filter is on. Publisher-level badv blocklists travel with every outbound request.
Supply sources are re-scored every hour on a 0 to 100 scale. A source that degrades goes into quarantine before it is banned, and the score is visible in the console rather than applied silently.
Every rejected request is written to the funnel log with a machine-readable reason code (no_ip_ua, browser_not_allowed, non_mainstream and the rest), so any filtering outcome can be reconstructed for a given time window.
We publish sellers.json, ads.txt and app-ads.txt at their canonical locations and pass source.ext.schain (v1.0) on every outbound bid request. A scheduled robot rechecks the ads.txt of connected properties and reports the result in the publisher console, so buyers never have to guess.
Demand responses are validated against the contract, not just accepted: currency, secure adm for HTTPS inventory, bcat / bapp / battr, seat allow and block lists, video protocols and creative dimensions against the imp we sent.
Documented rejection codes
A no-bid is an HTTP 204 with a reason attached to the request in our logs. Integration partners get the code, not a shrug.
Rendered creatives carry our own impression and click pixels. A dedicated collector batches those events into ClickHouse: log_rtb and log_event hold the impression and event streams, and a per-request funnel table records the verdict, reason, geo, domain, format, demand feed, bid, cleared price, margin and revenue share for every inbound OpenRTB request. Nothing is dropped silently.
Materialized views aggregate by minute, by hour and by day. An incremental ETL job upserts into the reporting stores behind the partner consoles using a stable hash key, so a rerun corrects data instead of doubling it. Partners read the same numbers we do, through the self-serve publisher and advertiser consoles, a reporting API and CSV export, down to placement, creative and rejection reason.
The serving process exports Prometheus counters, gauges and histograms labelled by format and by demand partner (requests, bids, timeouts, errors and latency) into Grafana dashboards. When a DSP degrades, we see it in its own series before anyone reports it.
Specifications
Standards
Adbustr is built on top of, not around, the standards the IAB Tech Lab has spent a decade defining. We are not asking the industry to trust us; we are asking it to verify us.
Start here
Publishers connect a site, an app or CTV inventory and get tags, player code or an OpenRTB endpoint. Advertisers launch banner, video, CTV, push, pop and native campaigns against moderated inventory. Both see fill, eCPM, spend and rejection reasons per placement in the same reports we read.
Sign-up is three screens: email, password, code. The console opens immediately; traffic starts after review.