Platform

More competition for every impression, and the logs to prove it.

SkyBoosts is a sell-side platform that runs a server-side, first-price auction across your in-app and connected TV inventory. Every demand source connected to your account, RTB seats, direct campaigns and mediated networks, is invited into the same decision for the same impression, and every input that shaped the outcome is written to a log you can query afterwards. This page walks through how the auction works, which supply surfaces feed it, and what you can verify at each step.

Talk to the platform teamIntegration docs
OpenRTB 2.6VAST 4.x / VMAPSSAIapp-ads.txt enforcementFirst-price auction

Illustrative auction · every demand source competes at once

OpenRTB 2.6First-price auctionVAST 4.xVMAP poddingSSAIschainOMIDapp-ads.txtsellers.jsonTCF v2.2GPPServer-to-server API
01 · What the platform is

Server-side decisioning for every impression you sell.

At the center of the platform sits a server-side auction. When a user reaches an ad break in your app or a pod boundary in your stream, the impression is packaged into an OpenRTB 2.6 bid request and offered to every demand source connected to your account at the same moment. Buyers respond with bids inside the timeout budget you set, the highest valid bid above your floor wins, and the winning creative is returned through the same call. There is no sequencing step that decides who gets to see the impression first, and no buyer that learns the clearing price before a rival has bid.

Two supply surfaces feed that auction. The SkyBoosts SDK collects and signals impressions from iOS, Android and TV applications across rewarded, interstitial, banner, native, playable and offerwall formats, attaching the client-side events that buyers' measurement and optimization depend on. Server-side ad insertion stitches advertising directly into streaming manifests for FAST channels and OTT apps, so that VAST 4.x creatives land in the pods your VMAP schedule defined and breaks behave the way you planned them.

Underneath both surfaces runs the reporting layer. It records what the auction decided, what the buyer actually paid and what the measurement stack observed, at impression level, and aggregates those records into the figures your invoices are calculated from. When a number in the dashboard looks wrong, the trail leads back to the bids that produced it, that is the standard the platform is built to, and the reason the rest of this page keeps pointing at things you can check rather than claims you have to trust.

02 · Auction mechanics

A single first-price auction with no favorites in the running.

Every demand source competes on every impression over OpenRTB 2.6, under first-price semantics that every buyer can model. Price decides the winner; validity, creative policy and your floors decide who is allowed to compete. Nothing else moves the outcome, and every input to the decision is logged.

A-01

Simultaneous competition

RTB demand, direct campaigns and mediated networks are evaluated inside the same decision window, so no source is polled ahead of another and no buyer sees the clearing price early. Every seat receives the same impression signal at the same time, which produces the kind of open competition that in-app bidding was designed for, and that sequential waterfalls systematically leave behind. The timeout budget is yours to set per placement, and seats that consistently answer late show up in reporting instead of silently dragging down fill.

A-02

No self-preference

SkyBoosts network demand competes on equal terms with external DSPs. There is no last look at rival bids, no bid shading applied in our own favor and no throttling of competing buyers while our own campaigns run. This is written platform policy, enforceable by pulling the auction logs for your own traffic.

A-03

Logged decisions

Every auction writes a record of the competing bids, the floor applied, the policy outcome and the clearing reason. Pull it through the reporting API when a placement underperforms, when a buyer asks why they lost, or when finance needs to reconcile revenue to delivery, the trail exists at impression level, not as a daily rollup. Exports use the same schema as the dashboards, so a number you contest and a number you report are the same number.

03 · Demand types

However demand reaches you, it competes on your terms.

The auction accepts three kinds of demand, and treats them by the same rulebook: the highest valid bid wins the impression, whoever the buyer is and however the deal was papered.

RTB

DSPs over real-time bidding

External buyers connect over OpenRTB 2.6 and receive every bid request their targeting qualifies for, from open-auction impressions to the deals you have negotiated. Deal IDs scope private marketplace and programmatic guaranteed access, so a buyer can commit to your inventory at agreed terms without stepping around the auction. Response rates, bid rates and win rates per seat show up in your reporting, which turns demand-side troubleshooting into a shared exercise instead of a support ticket.

DR

Direct campaigns

Brand and agency agreements traffic into the platform with fixed CPMs, frequency caps, pacing curves and competitive separation rules, exactly as your sales team sold them. Direct lines then enter the same auction as programmatic demand and win on price like any other bid, which removes the usual juggling act between sold IOs and the programmatic stack. When a direct campaign is outbid, you can show the sales team precisely what beat it and at what price, instead of arguing about it in a spreadsheet.

MED

Mediated networks

Ad networks without RTB endpoints still take part. Where a network supports in-app bidding it bids inside the unified auction; where it does not, the mediation layer manages it as a waterfall fallback ranked by historical performance on your inventory. You keep the partner relationships you already have, and you gain a single report that shows what each source actually earned after the auction settled, including the sources that used to be a black box.

04 · Supply surfaces

Where your inventory comes from.

The platform monetizes two very different kinds of supply, a software SDK inside applications, and ad insertion inside video streams, and gives both the same auction, the same policy engine and the same reporting.

In-app SDK impressions

Mobile + TV apps

The SkyBoosts SDK instruments applications on iOS, Android and the major TV platforms, with wrappers for the cross-platform engines teams actually build with. It renders all in-app formats, emits the impression and completion events that buyers' optimization depends on, and carries OMID signals so viewability and verification can be measured by the buyer's partner rather than asserted by us. Integration is a single dependency, with per-format quickstarts in the documentation.

iOSAndroidTV platforms

SDK overview

CTV server-side ad insertion

SSAI

Server-side ad insertion stitches advertising directly into the content manifest for FAST channels and OTT applications, so ad breaks start without the buffering or skipping that client-side rendering invites. Your VMAP schedule defines the pod structure, pod length, ad positions and separation rules, and the auction fills each slot while competitive separation is enforced across the whole break. Beacon forwarding keeps measurement intact even though the stitch happens server-side.

FAST channelsOTT appsVAST · VMAP · SSAI

CTV monetization

05 · Transparency and quality controls

What buyers can verify, and what you can audit.

Transparency here is a set of working mechanisms: standards-based signals that leave with every bid request, and enforcement that runs before the auction rather than after the invoice.

Supply chain

schain on bid requests

Every bid request carries the IAB Tech Lab supply chain object, so a buyer can trace each hop between your inventory and their seat without asking us for a mapping file. The object records each node's exchange and seller account IDs, whether that node expects payment, and whether the chain is complete. An auditable path means fewer unknown intermediaries taking margin, which is what supply path optimization rewards when buyers decide where to spend.

Registry

Seller registry

Every account ID in our seller registry maps to a legal entity with a declared relationship to the inventory it sells, publisher, intermediary or both, and that registry is what declarations are validated against. Combined with app-ads.txt enforcement it closes the loop on authorized selling. Who is allowed to sell what is written down, kept current, and checked on every request.

Enforcement

Authorized-sellers-only

Incoming traffic is checked against the app-ads.txt and sellers.json declarations we crawl and monitor on your properties. Requests that arrive through a path you never authorized are dropped before the auction, and the offending path is recorded in reporting so you can chase down whoever is reselling your inventory. Your app store listing cannot be monetized by parties you have never heard of, let alone agreed to.

Pre-bid

Invalid traffic filtering

General and sophisticated invalid traffic patterns are evaluated before the auction runs, against industry bot lists and our own anomaly signals. Filtered impressions never reach a buyer and never surface in your revenue; each one is logged with a reason code so you can see what was removed and why. Clean inventory keeps the CPMs it commands, and your standing with demand partners stays intact.

Measurement

OMID / Open Measurement

Formats that support Open Measurement expose viewability and verification signals through OMID to the measurement partner each buyer chooses. Mobile formats are fully instrumented, and on CTV we forward beacons wherever the platform's measurement interfaces allow. Delivery is verified by the buyer's own measurement vendor rather than self-reported.

Creative

Creative review

Creatives pass policy review before their first impression and are re-checked whenever a destination changes or a payload no longer matches what was reviewed. You can block categories, advertisers and domains per placement, and those blocks apply to direct and mediated demand too. Enforcement covers every lane, not only the RTB one where checks are easiest.

06 · Infrastructure

Built for decision windows, not demo environments.

The auction runs server-side, close to demand, with redundancy across regions and graceful degradation under load. When capacity tightens, demand shedding follows a published priority order rather than whoever shouts loudest. Current decisioning figures, the region list and capacity numbers are shared as live values during technical onboarding and refreshed with each release.

DecisioningServer-side, inside the OpenRTB timeout budget, with headroom reserved for CTV pod assembly.
RedundancyMulti-region failover for the auction, SSAI stitching and reporting ingestion, exercised on a schedule rather than during incidents.
Load behaviorDemand shedding follows a published priority: programmatic guaranteed is protected first, then private marketplaces, then open auction.
LIVE INFRASTRUCTURE

Illustrative region map · Multi-region decisioning

07 · Integration and scope

Four ways to plug in, and a clear line around what we do.

Integration surfaces

01

SDK

One dependency covers every in-app format and the mediation layer on mobile, with support for the major TV platforms. The documentation carries per-platform quickstarts, reference apps and migration notes, and the integration team reviews your build before you ship to production.

02

Server-to-server API

Publishers who run their own ad stack can inject impressions over the S2S API instead of adopting the SDK, and get the same auction policy, the same floors tooling and the same reporting. You keep your client; we supply the decisioning.

03

SSAI

CTV integration is set up per platform with our team: manifest manipulation, VMAP pod parsing, beacon forwarding and failover behavior. The work is scoped in onboarding, and the configuration lives in your account where you can inspect it.

04

OpenRTB seats

DSPs and networks connect as demand partners over OpenRTB 2.6, scoped by deal, format, platform and geography. Seat-level reporting shows what you bid, what you won and what you paid, without waiting on a quarterly business review.

CAPABILITIES

What the platform includes

Unified auctionManaged waterfallAutomated CPM optimizationA/B cohort testingDynamic floorsPMP and programmatic guaranteedAd podding with separationSSAI deliveryDeal-level forecastingapp-ads.txt crawl monitoringIVT pre-bid filteringImpression-level reporting APIDiscrepancy reconciliationLogged auction decisions
SCOPE

What we do not do

We are not a walled garden. The demand mix is dominated by external DSPs, agencies and brands, and the network campaigns we do run compete at par with everyone else's, a structural fact that keeps the auction honest in a way an integrated demand stack cannot match. We do not run user acquisition, and we do not resell inventory that app-ads.txt does not authorize. Those boundaries are what make the audit logs mean something.

No demand biasNo UA arbitrageNo unauthorized resale
08 · Questions we get from technical evaluators

The questions procurement should ask any SSP.

First-price, across all surfaces and all demand types. Buyers can model their bids accordingly because the semantics are the same for open auction, PMP and programmatic guaranteed, there is no hidden bid shading and no second-price surprise at reconciliation time.

Yes. The SDK supports hybrid mediation, so in-app bidding networks compete in the unified auction while non-RTB networks stay in a managed waterfall, ranked by their measured performance on your inventory. You can migrate network by network instead of ripping anything out on day one.

Reporting is built at impression level with the auction log attached, so discrepancies can be traced to the events that caused them rather than negotiated line by line. The reporting API exposes the same records your account team sees, so both sides reconcile from the same impression-level records.

On your side, integration needs access to the packaging or manifest pipeline for each TV platform you ship on, plus the lead times that platform requires for certification. On ours, the integration team handles manifest manipulation, VMAP pod parsing and beacon forwarding, and codifies your pod rules and separation policies into the platform configuration where they are enforced on every break.

Onboarding includes generating and publishing your declarations, then continuous crawl monitoring with alerts when the file changes or a new unauthorized seller appears. Enforcement is enabled once your declarations are live, so authorized-only filtering protects you from the first impression.

Decisioning times, capacity limits and regional coverage are documented during technical onboarding, refreshed with each release, and can be written into your evaluation criteria before you sign anything.

Platform access

See the platform from the inside.

Get the technical onboarding pack: auction policy, integration surfaces and current infrastructure figures for your inventory profile.

Contact the platform teamRead the documentation

OpenRTB 2.6 · VAST · unified auction