Skip to main content
GET /api/v2/buyer/discovery/{discoveryId}/discover-products Returns products from an existing session without spending another LLM-enriched discovery call. Filters narrow the cached result set in place. Use this to page across groups (groupOffset) and products (productOffset) after the first Discover products call.

Request

Parameters

Response

Returns the same DiscoverProductsResponse shape as discover. Browsing reads from the discovery snapshot cache (TTL 4 hours) — re-run POST /discover-products with the same brief to refresh after expiry.
The snapshot’s 4-hour TTL can outlive an individual product’s FX-quote hold (an FX-converted product’s expiresAt, at most until next UTC midnight). Scope3 enforces this server-side: if any product in a cached snapshot has passed its expiresAt, the snapshot is treated as stale and this call transparently re-discovers instead of paginating an expired price — you may see a fresh (unpaginated) result in that case rather than the exact page you requested. If you cache the response yourself, apply the same rule: never serve an item past its expiresAt.
When polling a progressive discovery with sinceRevision, the response additionally carries revision, resultsComplete, pendingAgents, and — while incomplete — a guidance string spelling out the exact next call, and productGroups contains only seller groups that landed after the revision you passed — with replace semantics (a group may be re-delivered with more products; replace it by groupId). Poll with each response’s revision until resultsComplete is true, or stop after roughly your wait budget and treat remaining pendingAgents like incompleteAgents. Inside Murph, the runtime owns continuation once discovery starts. It retains the same discovery identity and reads cumulative groups with sinceRevision: 0, so products from earlier responses remain available when the final result reaches the assistant. It makes at most eight dispatches within 30 seconds. An unfinished or ambiguous result, or accumulated result pages that exceed its response-size limit, is reported as incomplete; it does not mean that no matching products exist. Murph keeps the original request and does not automatically start a replacement or attach products after that limit. A completed discovery with zero products has no products to attach. Selected products still pass the campaign, account and current discovery-publication checks before attachment. If an initial request is rejected before discovery executes, you can correct it and retry in the same conversation. An error while an existing discovery is running, or one whose execution outcome is uncertain, keeps the original request protected from replacement. If one or more storefronts timed out or returned partial results for the requested wait window, the response includes incompleteAgents without requiring debug=true. When retryWithLongerWaitAvailable is true, you can browse again with waitMode: "long" or a larger waitSeconds value after confirming the buyer wants to wait longer. If retryWithLongerWaitAvailable is false, the response is already at the maximum interactive wait window. Murph follows completed get_products result pages using their returned cursor and retains earlier pages before attaching products. An exact repeat of a confirmed attachment is acknowledged without sending it again; different selections can still be attached. When its active continuation history reaches 100 confirmed attachments, Murph stops further distinct attachments and preserves earlier confirmations. Legacy synchronous discovery continues to use its existing attachment checks.

Errors

  • 400 VALIDATION_ERROR — invalid pricingModel or out-of-range pagination value.
  • 404 NOT_FOUNDdiscoveryId does not exist or is not visible to the authenticated account.
See Errors for the full error contract.

Discovery overview

Sessions, pagination, and caching

Discover products

Run discovery and open a session

Add products

Add a browsed product to the selection

Get products

List the current selection