Disclosure
A seller decides how much to reveal, and when. Availability and price are the two levers, and each is a choice, not a platform requirement. Publishing a full catalog with live avails and open rates is one posture; answering on request, or quoting each campaign, is another. All of them transact on the same rails and lock the same way. Disclosure is set per product and can be overridden per agreement, so you can publish to a buyer you trust and withhold from the open catalog.
Two levers: avails and pricing
Every product carries a disclosure block with two independent fields:
"disclosure": {
"avails_policy": "on_request",
"pricing_policy": "quote"
}
Both default to published, which is the behavior every other page assumes unless it says otherwise. Set either one to a tighter posture and the buyer flow moves from the catalog to a proposal: the buyer sends a brief, and you reveal exactly what the plan needs.
Avails: published, on request, or withheld
Signaling unsold inventory can move price against a seller, so many do not expose a feed at all. avails_policy names the choice:
| Value | What a buyer gets |
|---|---|
published | The tri-state avails feed: available, unavailable, or projected, with sellout levels. Today's default. |
on_request | No standing feed. A read returns 202 and the seller answers a scoped query, and may coarsen it (one figure per daypart rather than per break). |
withheld | Availability is never exposed. A read returns 409 AVAILS_WITHHELD pointing to the proposal path; availability resolves at seller review or inside a plan. |
Whichever you choose, the platform never invents availability, and availability stays the only legitimate business rejection under the price-clearance invariant.
Pricing: published, agreement, or quote
Price can be a standing number or a per-campaign one. pricing_policy names the choice:
| Value | What it means |
|---|---|
published | An open rate card, visible to any authorized buyer. |
agreement | A buyer-scoped card, the deal-ID pattern: rates only that buyer can see, unlocked by presenting the agreement. |
quote | Priced per campaign. The seller mints a quote inside a plan response, or in a counter at the review gate: a rate-card commit with commit_kind: "quote", an agreement scope, and a quote_expires_at. It locks like any card the moment the buyer confirms; an expired quote is a stale card (STALE_RATE_CARD), which converts to "re-request a quote," never a silent rejection. |
Per buyer: the resolution chain
The product's disclosure is the seller's standing posture. An agreement can override it per buyer, through disclosure_overrides: an array of {product_id, avails_policy?, pricing_policy?} entries, where product_id may be "*" for everything the relationship grants.
"disclosure_overrides": [
{ "product_id": "*", "pricing_policy": "quote" },
{ "product_id": "acme-prime", "avails_policy": "on_request" }
]
Each field resolves on its own, most specific first:
override(product_id) ?? override("*") ?? product.disclosure ?? published
Per field is the whole subtlety. An entry that omits a field is transparent for that field: it falls through as though the entry were not there. So in the example above, acme-prime answers on_request for avails and quote for pricing, because the named entry says nothing about pricing and the wildcard still governs it. Reading each entry as a unit instead would have the narrower entry silently reset the field it did not mention, which is how two independent postures become one wearing two names.
Two rules keep the array unambiguous. One product_id may appear once: a duplicate is refused 422 DUPLICATE_DISCLOSURE_OVERRIDE rather than resolved by array order, because which entry wins should not be an accident of how they were sent. And an override naming a product outside the relationship's catalog_scope is a no-op, so a stale entry cannot start governing a product a later grant adds.
Buyers never set disclosure. It is the seller's declaration about the seller's own inventory, on both sides of the override.
Disclosure is not a level
Withholding avails is not a sign of a low-capability seller. It is a commercial choice, and often a sophisticated one. A Level 3 seller with a real-time system may still run withheld avails and quote pricing because that is how it protects yield. Do not read a missing feed as a missing capability: avails_policy and pricing_policy are orthogonal to your Seller Level, and on_request and withheld are served through the proposal path, never by degrading you to batch intake.