What is the IAB Tech Lab Deals API, and what does it change for deal setup?
Part of Curated deals and PMPs
The short answer
The IAB Tech Lab Deals API is a standard for sending a deal's agreed terms from the system that created the deal, such as an SSP, to the system that will bid on it, such as a DSP. Version 1.0 was in public comment until January 31, 2026 and was finalized on February 6, 2026. It replaces retyping, not checking.
Key takeaways
- IAB Tech Lab's Deals API version 1.0 was finalized on February 6, 2026, after public comment closed on January 31, 2026.
- It is a push: the origin system posts the deal to an endpoint the receiving system runs, then can query that system for the deal's status per buyer seat.
- It carries terms, inventory and curation facts, such as dates, countries, floor guidance, currency, price type and site domains.
- It sits outside OpenRTB, and the specification tells buyers to keep validating bid requests against the terms it sent.
- A final specification does not prove that a given SSP or DSP has built it.
What is the IAB Tech Lab Deals API?
Definition
- Deals API (Deal Sync API)
- An IAB Tech Lab specification for an HTTP POST endpoint, run by the receiving system, that accepts a deal's terms pushed from the origin system where the deal was first entered.
Without a shared API, a private marketplace or curated deal can be entered twice: the seller sets it up on the exchange, then sends the ID and terms by email or spreadsheet for someone to retype in the buying platform. The Deals API specification (opens in a new tab) states three goals: decrease manual entry of deal information across systems, describe what the selling system deal includes at a high level, and know which parties were involved in curating and selling the package.
The specification calls version 1.0 an MVP with a one-party design: the origin system pushes information about the deal into the receiving systems from the system where it was created, for example SSP to DSP, and can later query the receiving system for the deal's status. Tech Lab's Deals API page (opens in a new tab) describes the same split: terms move from the system that created the deal, such as an SSP, to the receiving system, such as a DSP.
When was the Deals API finalized?
IAB Tech Lab released version 1.0 for public comment in December 2025. The comment period ran until January 31, 2026, and Tech Lab finalized version 1.0 on February 6, 2026. The specification's public change history (opens in a new tab) shows what moved during that window: comment feedback added a curator deal ID and a pending value for seller status, and the final changes removed a proposed Content object from the MVP so it could be added later with more care.
| Date | Event | What it means for buyers |
|---|---|---|
| December 2025 | Version 1.0 released for public comment | The draft could still change |
| February 5 and 6, 2026 | Comment changes approved; Content object removed from the MVP | Content details are not in version 1.0 |
| February 6, 2026 | Version 1.0 finalized | Partners can build to a stable document |
| February and March 2026 | Errata to the sellerstatus value list | Read the current file, not an early copy |
What deal information does the Deals API move?
The payload is a Deal object with a required Terms object and optional Inventory and Curation objects. Fields beyond the required ones are optional, so what arrives depends on what the origin fills in.
| Field | Object | What the specification says it holds |
|---|---|---|
| id | Deal, required | A unique identifier for the direct deal in the origin's namespace |
| name and desc | Deal | The deal name as created in the origin system, which may be shown to the buyer, and a short description, ideally 250 characters or less |
| origin and seller | Deal | The advertising system domain that will receive bid responses, typically the SSP, and the canonical domain of the entity that sold the deal |
| wseat or bseat | Deal | Allowed or blocked buyer seats; at most one should be used |
| adtypes | Deal | Formats supported: 1 banner, 2 video, 3 audio, 4 native; empty means all |
| startdate and enddate | Terms | UTC timestamps; evergreen deals leave the end date blank |
| countries | Terms | Country codes where the deal is available; empty means all countries |
| dealfloor and cur | Terms | Minimum bid in CPM, guidance only unless pricetype is Fixed, and a currency that defaults to USD |
| pricetype, guar, units, totalcost | Terms | Dynamic, first price, second price plus or fixed; whether guaranteed; units and total cost should be provided for guaranteed deals |
| sitedomains, appbundles, sellerids | Inventory | Domains, app bundles and seller account IDs, included only for a static set of sites or apps |
Several of these mirror the Deal object in the OpenRTB 2.6 specification (opens in a new tab), described in our OpenRTB deal object guide: dealfloor sits next to Deal.bidfloor, cur next to Deal.bidfloorcur, guar carries the same meaning, and a fixed pricetype describes the same arrangement as Deal.at set to 3. The difference is timing. The Deals API states the terms once, before the deal runs; OpenRTB states them on every impression.
The sellerids field connects to supply checks. Its values must match the value used in transactions, typically publisher.id in OpenRTB, and an empty list implies the deal may run across all sellers. A buyer can compare the sellers a deal names with those in sellers.json and in live requests.
Which systems send and receive deal terms?
The origin is the system with the user interface where the deal is first input, typically an SSP. The receiving system, typically a DSP, runs two endpoints: one accepts pushed deals, the other lets the origin request current information for a deal, answered with a BuyerSeat object giving a status for each buyer seat.
| Value | Status in the buying system | What a seller learns |
|---|---|---|
| 0 | Pending approval | The buyer has not reviewed the deal yet |
| 1 | Buyer has approved; a non guaranteed deal is ready for bid requests | Requests can be sent |
| 2 | Buyer has rejected | Terms need a conversation |
| 3 | Ready to serve; the deal is in a campaign, relevant especially for guaranteed deals | A line item points at the deal |
| 4 | Active, serving impressions | Delivery has started |
| 5 and 6 | Paused; complete | The buyer side has stopped or finished |
Where several seats are included, per seat acceptance or rejection is on the DSP to surface in its own interface. Receivers are encouraged to poll periodically as a fallback for missed notifications, because version 1.0 does not support differential overrides; the document says version 1.1 will.
What does the Deals API not do?
The specification lists its limits in its own words, and each one is a reason a buyer's checks stay in place. It is a separate API that is not included in the OpenRTB request or response. It does not include real-time information or determine whether a deal applies to an impression. Its MVP does not support proposals, revisions or negotiations, which are assumed to be known to both sides in advance, and it is not meant to support discovery in deal marketplaces.
Floors are a special case. The specification notes that many SSPs and curators package media around data points not tied to the inventory, so prices vary request by request, and that dealfloor is guidance unless pricetype is Fixed. Check the price type before treating the number as a price.
What should buyers ask partners about Deals API support?
A final standard is not the same as a built integration, and the specification makes no claim about who has implemented it. The questions below turn support into something a partner can answer in writing.
Deals API questions for an SSP, curator or DSP
- The partner states whether it sends or receives Deals API 1.0 today, for which account types, and since when.
- The partner names which optional fields it fills, especially countries, adtypes, sitedomains and sellerids.
- The partner says whether its seller status codes follow the current specification file, after the 2026 errata.
- The partner explains where targeting is set, since the specification asks both sides to discuss delivery effects when targeting sources differ.
- The partner says how often a receiver polls for updates, given that version 1.0 has no differential overrides.
- The buying team keeps validating live bid requests against the pushed terms whatever the answers are.
What does Deals API readiness look like on a real brief?
Fictional example
A prairie credit union's trading desk prepares for pushed deals
A fictional credit union in Winnipeg runs display for auto loans beside car buying, personal finance and local news content in Manitoba and Saskatchewan, in English, priced in CAD. Its trading desk buys three curated deals from two sellers and has typed every deal by hand so far.
Before the next flight the desk sends each partner the checklist above. One seller says it pushes deals by API and fills countries, adtypes and sitedomains; the other still sends deal IDs by email. The desk's buying platform confirms it can receive pushed deals for approval by seat.
The desk compares the pushed deal with the deal sheet: the countries list reads CAN, the currency is CAD and the domain list matches the approved version. It approves the deal for its seat, sets Manitoba and Saskatchewan targeting on the line item itself, and samples bid requests in the first days to confirm the terms hold.
How does PlacementGraph fit before a deal reaches the Deals API?
Frequently asked questions
Is the Deals API part of OpenRTB?
No. The specification says it is a separate API that is not included in the OpenRTB request or response. Deal terms move once, before or during setup, through the Deals API, while each bid request still carries its own Pmp and Deal objects. Both have to agree for a deal to behave as planned.
Can the Deals API be used to negotiate a deal?
Not in version 1.0. The specification says the MVP does not support proposals, revisions or negotiations, which are assumed to be known to both sides beforehand. It adds that future versions will likely consider this, and that bi-directional communication is also likely to come later.
Does the Deals API list every site in a curated deal?
Only when the inventory is fixed. The Inventory object, with sitedomains and appbundles, should only be included when the deal is for a static set of sites or applications. When dinventory says sites may change during the flight, the pushed deal may not list them at all, so ask for the list separately.
What is the difference between origin and seller in the Deals API?
The origin is the system where the deal was first entered, typically the SSP that receives the bid responses. The seller is the business that sold the deal to the buyer: the origin, the curator or another company. The specification's example names a sales house, a curator and an SSP as three parties.
Sources
- Deal Sync API specification 1.0 (opens in a new tab)IAB Tech Lab
- Deals API (opens in a new tab)IAB Tech Lab
- Deal API repository change history (opens in a new tab)IAB Tech Lab
- OpenRTB 2.6 specification: Pmp and Deal objects (opens in a new tab)IAB Tech Lab
- sellers.json specification (opens in a new tab)IAB Tech Lab
Researched and written by PlacementGraph Research. Read how we research, source and update these pages. Corrections: diana@placementgraph.com.