The Deals API is a technical standard from IAB Tech Lab that lets the system where a programmatic deal is created, usually a supply-side platform (SSP), send that deal's agreed terms directly to the systems that will buy against it, usually demand-side platforms (DSPs). It exists because deal setup has long depended on people retyping the same information into different interfaces. Terms agreed by email were entered once by the seller and again by the buyer, with each platform naming the fields differently. The Deals API replaces that second entry with a machine-readable push, and adds something the bid stream never carried: a record of who packaged and sold a curated deal, and what kind of fee they charge.

How the Deals API works

Version 1.0 is deliberately narrow. The specification calls itself a "one-party design": the origin system pushes information about a deal into one or more receiving systems, and can later ask those systems for the deal's status. Both calls are HTTP POST requests to endpoints the receiving system implements.

The sequence runs in four steps. A seller and a buyer agree terms outside any machine, which the specification assumes are known "a priori". The seller, or a curator working through the seller's platform, enters the deal in the SSP. The SSP then posts a Deal object to each DSP named in the deal. Finally, the SSP polls the DSP's endpoint, which returns a BuyerSeat object listing, seat by seat, whether the deal is pending approval (0), approved (1), rejected (2), ready to serve (3), active (4), paused (5) or complete (6). Ready to serve matters most for programmatic guaranteed deals, which deliver only once inside a live campaign.

The Deal object has three required fields. The id is the deal's identifier in the origin's namespace, and it must match the deal ID that later appears in OpenRTB bid requests. The origin is the advertising system domain that will receive bid responses, typically the SSP. The terms object carries the commercial core: start and end dates in ISO-8601, a country list, a dealfloor expressed as a cost per thousand impressions (CPM), a currency defaulting to US dollars, a guar flag for guaranteed deals, and a pricetype where 0 means the auction type is set per request, 1 is first price, 2 is second price plus and 3 is fixed price. Guaranteed deals should also state units, the impressions promised, and totalcost.

Around those sit optional fields that describe the package. Seat allow and block lists, wseat and bseat, mirror their OpenRTB counterparts. An inventory object can list site domains, app bundles, seller account IDs, device types and content categories, but only when the deal runs on a fixed set of properties.

The curation fields

The transparency fields are what distinguish the Deals API from older deal-sync integrations. Three domains identify the parties. origin names the platform where the deal was entered; seller names the company that contracted with the buyer; and a separate curation object names the curator, the entity that packaged the inventory, technology or data, together with that curator's own identifier for the deal in cdealid.

The specification's worked examples show why three fields are needed. In one, a sales house sources the demand, a curator runs operations and blends data from several providers, and the deal is entered in an SSP, so each field names a different company. In another, a publisher selling its own deal with a data provider's help is the seller, and the data company is the curator.

Four coded fields then describe the package without disclosing prices. curfeetype states whether a curation fee is a percentage of spend (1), a flat fee (2), a CPM (3) or not charged (4), with 0 for undisclosed. auxdata flags whether non-publisher data with a fee is applied, and whether that can change mid-flight. pubcount separates single-publisher from multi-publisher deals. dinventory says whether sites and apps can be added or removed after launch. A curator charging a CPM to aggregate many publishers, adding data partners as the deal runs, would send 3, 2, 2 and 2. The form of the fee is disclosed, its size is not: a curator charging USD 5 CPM sends the value 3 and nothing about the USD 5.

Origin and evolution

The repository behind the standard was opened on GitHub on September 15, 2025, and the first draft of the specification, then titled "Deal Sync API Specification", was committed on October 22, 2025 by Hillary Slattery, IAB Tech Lab's senior director of programmatic product management. IAB Tech Lab announced the draft for public comment in a press release dated December 4, 2025; PPC Land dated the release to December 5. Comments closed on January 31, 2026.

The comment draft defined guar with 0 meaning guaranteed and 1 meaning not guaranteed, the reverse of OpenRTB; the final version aligned it with OpenRTB, where 1 means guaranteed. The cdealid field for the curator's own deal identifier was added, sellerstatus gained "pending" and "complete" values, and guidance was added on deciding which system applies targeting. Version 1.0 was merged and tagged as final on February 6, 2026. Errata followed on February 26 and on March 30, 2026, the latter correcting a sellerstatus list that had assigned the value 4 to both "complete" and "archived".

Proprietary versions came first. Google's Display & Video 360 (DV360) offers exchanges its own Deal Sync API, whose deals buyers accept from a Negotiations page. Without a shared schema, each SSP had to build a separate integration for each buying platform.

Why it matters

Deals are now routine in programmatic buying, and they fail often. The Trade Desk said in June 2025 that roughly 90% of deal IDs fail to scale, an internal figure. "Two-thirds of deals are configured with the desired supply, yet deliver no or very little revenue," Nick Allen, vice president of product management at Magnite, said in IAB Tech Lab's December 2025 release. Mis-keyed fields are one cause the standard can remove.

Integration cost is another. Jochen Schlosser, Adform's chief technology and product officer, put a custom deal sync integration with one SSP at 250 to 350 days of work, against about 50 days on a shared standard, an estimate IAB Tech Lab quotes on its Deals API page.

Curation gives the third reason. Curators assemble inventory and audience data from many sellers under a single deal ID, and a buyer seeing that ID in a bid request cannot tell who built the package or how they are paid. "As the curation category matures, media buyers and their DSP partners should have basic line of sight into the companies that are packaging inventory," Chris Kane, founder of Jounce Media, said in the launch release. PPC Land's curation explainer sets out the fee structures the curfeetype codes describe.

Limitations and disputes

The specification is candid about what it does not do. It is "NOT included in OpenRTB Request/Response", so nothing it says travels with an impression. It does not decide whether a deal applies to a given request, and it warns that terms "are not guaranteed to be accurately reflected in bid requests". Buyers are told to apply the deal's targeting in their own DSP and to validate the supply path through OpenRTB's SupplyChain object, because the API cannot prove a seller is authorised.

Version 1.0 also omits proposals, negotiation, marketplace discovery and differential updates when a term changes. The text says version 1.1 will add those overrides, and recommends periodic polling until then. As of October 2026 no version 1.1 has been published in the repository.

Disclosure is partial by design. curfeetype reveals a fee's form, not its size, and auxdata confirms that paid third-party data is present without naming the provider. Every coded field accepts 0, "undisclosed".

The text carries inconsistencies. The fee field is called curfeetype in the object table but curationfee in the implementation guidance. Country codes are specified as "ISO-3166-3", which is the standard for formerly used country names; OpenRTB uses three-letter ISO 3166-1 alpha-3 codes. Neither IAB Tech Lab nor the launch coverage lists production implementations.

Deals API versus adjacent terms

OpenRTB Deal object. The deal container inside each bid request, explained in PPC Land's OpenRTB explainer. It carries the ID, floor and seats in real time with each impression; the Deals API carries the agreement once, before any request is sent.

DV360 Deal Sync API. Google's proprietary interface for exchanges to push deals into Display & Video 360. Google's roadmap made it, from around April 2026, the only way to create new non-guaranteed deals in DV360. It does the same job for one buyer platform, without the curator fields.

OpenDirect. IAB Tech Lab's API for buying reserved, guaranteed inventory, covering orders, line items and proposals. It handles the negotiation and booking that the Deals API assumes have already happened, as PPC Land's programmatic guaranteed explainer describes.

Deal ID. The identifier itself. The Deals API transmits the terms attached to a deal ID; it does not create the ID.

Recent developments

The standard is being absorbed into agentic buying. IAB Tech Lab's open-source Seller Agent describes itself as built on "OpenDirect 2.1, Deals API v1.0, sellers.json" and pushes deals to buyers "via IAB Deals API v1.0 standardized push", alongside distribution through PubMatic, Index Exchange and Magnite. In September 2026, AAMP 3.0, IAB Tech Lab's agentic protocol suite, introduced an OpenProposal draft in which each agreed line item executes through OpenDirect 2.1, the Deals API or OpenRTB 2.6, depending on its transaction_mechanism field; comments closed on October 22, 2026.

The verification gap is being addressed elsewhere. IAB Tech Lab's June 2026 programmatic auction definitions include a seller-side check that "bids with deal IDs conform to deal terms", the kind of matching the Deals API leaves to implementers.

Timeline

  • September 15, 2025 - IAB Tech Lab opens the deal-api repository on GitHub.
  • October 22, 2025 - First draft of the Deal Sync API specification committed.
  • December 4, 2025 - IAB Tech Lab releases the Deals API for public comment.
  • January 31, 2026 - Public comment period closes.
  • February 6, 2026 - Deals API 1.0 marked final and tagged in the repository.
  • February 26, 2026 - First errata published.
  • March 30, 2026 - Errata fix duplicate values in the sellerstatus list.
  • April 2026 - DV360's own Deal Sync API becomes the only route for new non-guaranteed deals in that platform.
  • May 26, 2026 - Latest edit to the version 1.0 text.
  • June 2026 - IAB Tech Lab's auction definitions add a check that deal bids conform to deal terms.
  • September 22, 2026 - AAMP 3.0 draft names the Deals API as one execution route for agreed proposals.
  • October 22, 2026 - AAMP 3.0 comment period closes.

Summary

Who. IAB Tech Lab wrote and maintains the standard, led by Hillary Slattery. SSPs and other origin systems send deals; DSPs and other buying platforms receive them; curators, sales houses and publishers are named in its seller and curator fields. Magnite, Basis Technologies and Jounce Media commented publicly at launch.

What. A separate, HTTP-based API that pushes a deal's agreed terms, status and curation disclosures from the system where the deal is created to the systems that will bid on it, and lets the sender check approval status seat by seat.

When. Drafted in October 2025, released for comment on December 4, 2025, finalised as version 1.0 on February 6, 2026, and corrected through errata in February and March 2026. A promised version 1.1 had not appeared as of October 2026.

Where. Between platforms, outside the bid stream: alongside OpenRTB rather than inside it, and increasingly inside AI seller agents that create and distribute deals.

Why. Manual re-entry of deal terms causes misconfigured deals that fail to deliver, custom integrations between each SSP and DSP are expensive, and curated deals hide who packaged them and how they are paid. The standard addresses the first two directly and the third only partly, since it discloses fee types but not fee amounts.