Deal API 1.0 Public Comment Feedback

[hillslatt]

Feedback on scope and functionality pertaining to the Deal API MVP.

Public Comment period closes Jan 31, 2026

[bmayd]

The Deal Object doesn't provide information for lifecycle management of the deal record.

• It contains a created field that is defined as the deal creation timestamp, but does not include a modified field to indicate when a deal was last updated.
• It doesn't include any sort of version information and given that the parties are expected to iterate on the deal definition prior to finalizing it, it seems like having information to track revisions will be necessary to maintain alignment between parties. Perhaps something as simple as a numeric value that is incremented each time the deal is revised.
• It doesn't include a "pending" status in the sellerstatus enumeration. Given that the parties are expected to iterate on the deal definition prior to finalizing it, it seems like having a way to distinguish deals that are in the process of being defined, but not ready to go active would be important. Although the sellerstatus field could be used to indicate "pending" status, it may make more sense to have a separate dealstatus field to indicate if a deal is pending, under review (the buyer is reviewing), finalized (buyer has accepted), canceled, etc.
• There is no indication of what fields can be modified and which should not be as a deal is iterated on. Presumably the id and created fields should not be modifiable after the deal is initially shared with partners and potentially other fields should only allow limited changes.

[mmullin]

Does it make sense to also include a content object within the Inventory Object?

[kzoltowski]

I would recommend adding some kind of way for a Curator to assign his own ID to a Deal, with something like a Curator ID field in the Deal Object.

Today, many curators create not only multi-publisher curated deals, but also multi-SSP deals. As a result, buyers often need to accept a separate deal per SSP, even though these deals originate from the same curator and have identical settings.

In practice, there is no easy way for a buyer to identify that multiple Deal IDs from different SSPs represent the same curated offering. A Curator ID field would allow curators to assign their own identifier to such deals, enabling buyers to recognize and group equivalent deals across SSPs and accept them all at once if needed.

The Curator ID would not need to be globally unique and could be namespaced (e.g. curator name prefix + internal ID) if required.

[kzoltowski]

After further reading, I've also would like to recommend one more minor suggestion:

• appbundles and sitedomains in the Object: Inventory assume that these will be always on the allowlist. There should be an option to list appbundles and sitedomains as blocked, the same way it is done with wseat and bseat in Deal Object

[ChrisBasis]

The Curator ID would not need to be globally unique and could be namespaced (e.g. curator name prefix + internal ID) if required.

I like this idea. A prefix is not necessary as we already have the origin domain. All that would be required is to add an origin_id field.