Skip to main content
An RFP is one commercial opportunity on your storefront: a buyer’s brief that arrived over AdCP, one you typed in, one you imported, or a practice brief. An RFP turn is one request and the storefront agent’s response to it. Turns are immutable: revising a response appends a new turn instead of rewriting the old one. You can work RFPs in the Demand inbox and the proposal studio (open_page with page: "proposal_studio"), or entirely over MCP with save_rfp. The account must be a seller account.

Create an RFP and poll the turn

save_rfp
The call returns at once with rfpId, turnId and turnState. Poll the turn with get (kind: "rfp_turn", the turnId) or GET /api/v2/storefront/rfp-turns/{id}: queued → processing → ready | passed | needs_clarification | failed A counter-pitch can carry limitations, for example an age range none of the products can deliver (see Targeting).

Continue the lifecycle

save_rfp takes one action at a time; fields from another action are refused. Over REST, POST /api/v2/storefront/rfps takes the same actions; GET /rfps and GET /rfps/{id} read RFPs with their turns.

Render a response

request_representation with representation.format: representation.audience is buyer_delivery (the default: what you send a buyer) or seller_preview (for your own review). Representations move through queued, processing, ready, failed and canceled. Download a ready one with GET /api/v2/storefront/rfp-representations/{id}. PowerPoint (pptx) isn’t available yet and is refused with CAPABILITY_NOT_SUPPORTED.

RFP performance

get_rfp_performance (optional range and metrics) reports: A metric with no inputs is reported as unavailable, never as 0.

Not available yet

  • Releasing a turn for delivery and recording the commercial outcome over MCP (release_turn, record_outcome).
  • Required Library units and endorsed pairs that a turn must follow, and buyer-proposal JSON.