Product composition

Product composition lets your storefront assemble buyer-ready products on demand instead of returning a fixed catalog to everyone. When a buyer sends a brief, the Merchandising Agent builds products for it — selecting from your inventory building blocks, applying your operating instructions, pricing them against your Playbook pricing, and returning products shaped for the brief in front of it. A composed product is indistinguishable from a hand-authored one to the buyer — it carries a name, description, targeting, canonical format_options[], and pricing. The difference is that you never had to author it: the agent built it from your rules. When a composed product is backed by your static avails feed, it also carries an ext.scope3_merchandise block: the actual property each backing avail runs on, its available delivery for that avail’s own window, and any audience facts your product marketing has taught for that channel — all resolved from your own data, never invented. This block is not exclusive to composition: a buying_mode: "wholesale" response carries the same ext.scope3_merchandise block for the same static-avails-feed products, since it’s read from your inventory data directly rather than produced by composition. See the story-first proposal for the full field-by-field explanation. Composition is deterministic where it matters — the same brief against the same inventory and rules returns products with stable ids, so a buyer who discovers again sees the same products rather than a fresh set each time.

​

How the product path is selected

Product composition is not a separately priced add-on and has no Storefront-wide on/off switch. Each inventory source has an explicit product contract:

• Storefront-built supplies ingredients that Apostra turns into buyer-ready products.
• Agent-supplied supplies complete products that Apostra preserves and routes back to that Sales Agent.
• Both product paths supports both flows; each Source selects one or both.

The Sales Agent provider owns that declaration. Apostra Source pages show it read-only. Apostra support handles declaration and both-path selection reconciliation; Storefront operators cannot change the contract with a local toggle. The Storefront-built path needs these things in place:

1. A ready wholesale source. The source must declare and implement the AdCP 3.1+ wholesale product contract. Ordinary buyer-facing products are never guessed to be ingredients.
2. Author operating instructions. Composition can’t run without rules — an active operating-instructions ruleset tells the agent what to build and how. If a Storefront-built path is ready but no active ruleset exists, the storefront auto-pauses and notifies you rather than composing blindly.

If diagnostics say the wholesale path is not ready, correct the Agent’s product, property, format, pricing, or execution declaration as reported, then ask Apostra support to refresh or reconcile the capability. Apostra does not infer a new mode from catalog contents. Optionally, set Playbook pricing so composed products are anchored to your rate card’s floors, targets, and ceilings.

​

Provider adapter catalog snapshots

For a storefront connected directly to a supported provider, each successful wholesale discovery refreshes a durable snapshot of every product the adapter returned. The seller product list combines that snapshot with products from any managed ad-server sources, using the adapter’s stable catalog ids so products do not appear new merely because a buyer started another discovery session. The snapshot update runs after discovery and never holds up the buyer response. That also means a newly connected adapter does not appear in the seller product list until its first successful wholesale discovery finishes. The snapshot is a catalog view, not permission to buy: every live buyer request still refreshes account-specific availability and pricing and receives product ids scoped to that buyer’s provider account.

​

What a buyer sees

Composed products are returned in ordinary product discovery. The buyer submits a brief; the agent returns products (and, where configured, multi-product proposals with budget allocations across them). Each product is priced server-side and clamped to the [wholesale floor, seller ceiling] range, so a composed price is never below your cost. Creative delivery is canonical end to end. The composed product exposes the selected URL-free format_options[]; when a buyer pins one with format_option_refs[], Apostra resolves it back to the exact source option or direct format_kind and params selector. Source compatibility adapters may normalize an older named format at ingestion, but composed products never expose that source’s legacy URL-based format identity. That source option must still have the same identifier, format kind, parameters, and publisher scope when the buyer submits the media buy. If the source product changed after composition, the storefront rejects the stale selection and asks the buyer to discover the product again. It never substitutes another option merely because its dimensions look the same.

​

Watching it work

Every composition run is observable. Use intelligence runs to see what the agent composed for a given brief and why — the inventory it drew on, the rules it applied, and the rationale behind each product.

​

Related