Picture this: You’re a media buyer. You’ve got 17 systems, 5 supply-side platforms (SSPs), 3 demand-side platforms (DSPs), and a zoo full of “deal flows.” Each SSP names its deals differently, each with their own special notations for the terms of the deal that require you to telepathically decode the meaning. That once-elegant deal outlining clear terms now looks like a NASA mission control board built by toddlers (with apologies to toddlers if that is too harsh!): random strings, optional fields, missing metadata, and “special snowflake information” that work only in some corners of the universe. Meanwhile, Ad Ops teams are shouting at you though Slack, “No that Deal ID is from the old package! Use the new one!” and nary a soul is quite sure which “new one” they mean.
Now imagine a world where all the entire ad-tech gang agree on a single deal-API spec. One standardized schema. One set of fields. An outline of the parameters of the deal that everyone reads the same way. That’s what the new IAB Tech Lab Deals API specification (in Public Comment until January 31, 2026) is trying to provide: a common language for deals. Instead of a Tower of Babel across your eleventy billion stacks, we get a single shared language.
Why that helps:
- Faster onboarding. Want to spin up a new deal? If everyone speaks “deal-api” there’s no more “Hey sorry can you figure out what these 14 custom fields mean?” emails at 2 AM.
- Less deal drama. Buyers and sellers stop playing “Guess That Deal ID Format.” Instead they rely on a common spec, thereby reducing mis-matched deals, failed auctions, or worse: not figuring out what the problem is until after the end of the flight.
- Forensics made easy. Debugging a problem or investigating a shady supply chain? If every deal emits standardized metadata, you can trace provenance, catch suspicious patterns, and fix things before they become horror stories.
If you already have a Deal API, not to worry! We made sure every field in this standardized API either already exists in a way that does not conflict, or are net new to the world (hello Object: Curation). We looked at as many existing APIs as we could find and we’re confident that all implementers will have to do is map their fields to our fields. It’s also why we kept things relatively small for Version 1. Easy peasy.
As with the APIs that make up the LEAP (Live Event Ad Playbook) – Concurrent Streams, Forecasting (coming in early 2026!) and Biddable (name is a WIP, coming mid-2026!) – this API work as a sidecar to the core OpenRTB specification, and can be called independently and asynchronously from the main planning and operations workflow, to update tools as needed, and to keep them in sync.
The following illustration shows how the different specifications work together:
When used together, they form a powerful foundation whose whole is significantly greater than the sum of the parts.
Ad-tech is complicated enough; lots of players, lots of edge cases, lots and lots and lots of legacy baggage. A standardized Deals API gives much needed transparency into the high-level tenants of the deal but, more importantly in my opinion, also has a trifecta of transparency: who sold it, who packaged it AND who curated it. Version 1 is just the beginning. Review the specification today, and if you have suggestions for what should be part of version 2, join the Deals API Working Group.
You’re welcome.
Hillary Slattery
Sr. Director, Programmatic, Product Management
IAB Tech Lab