US MAP Retail Evidence

US retail catalog and minimum-advertised-price evidence processor for supplied Apify Dataset rows. It produces one deterministic report containing exact-ID evidence, MAP status, seller authorization, availability changes, absence assessments, and review actions that are explicitly not sent.

Quick start

Use exactly one source: inline rows or a buyer Dataset ID.

{
  "schemaVersion": "1.0",
  "requestId": "auto",
  "watchId": "lego-watch",
  "watchUniverse": ["tcin:16747749"],
  "rows": [
    {
      "adapter": "target",
      "sourceRecordId": "target-16747749",
      "sourceName": "target_probe",
      "observedAt": "2026-08-06T11:03:21.195Z",
      "data": {
        "tcin": "16747749",
        "upc": "673419233606",
        "productTitle": "LEGO Classic Large Creative Brick Box",
        "brand": "LEGO",
        "price": null,
        "availability": null,
        "url": "https://www.target.com/p/example/-/A-16747749"
      },
      "mapCents": 2999
    }
  ],
  "options": {"maxItems": 100, "explanation": "off", "analysisModel": null}
}

This example keeps Target's null price and availability as null. For a canonical row use adapter: "canonical_rows", one exact identity field, and the same source metadata. The native mappings are grounded in the committed probe fixtures for Google Shopping, Amazon, Walmart product detail, and Target. Only a public USD integer-cent base price can produce below_map; restricted, member, coupon, non-USD, fractional-cent, and conflicting-variant prices stay indeterminate.

requestId: "auto" is a task-safe sentinel. On Apify it resolves before input validation to the trusted actorRunId, so each Actor run has its own delivery idempotency scope while a replay of that same run never charges twice. Explicit non-auto IDs keep their existing idempotency behavior. A remote run fails closed if Apify cannot provide actorRunId; the deterministic fallback exists only in test mode.

Output and semantics

One useful run writes exactly one report Dataset item with pushData(report, "result-found"). Empty, invalid, all-unavailable, or insufficient input writes only OUTPUT. The terminal statuses are complete, complete_empty, partial_pagination, partial_budget, source_unavailable, delivery_unknown, bootstrap_required, and bootstrap_retry. The two bootstrap statuses and complete_empty are free: a new watch creates and verifies one persistent RequestQueue seed, then asks the caller to retry the same input after bootstrap.retryAfterMs. Bootstrap never reads evidence, writes a report or baseline, or emits result-found. For a closed Dataset with expectedItems: 0, complete_empty truthfully marks every configured identity absent, writes only OUTPUT plus a free baseline snapshot, and emits no result-found event. Partial or unavailable runs do not advance the watch baseline. A complete run advances it only after the result counter confirms exactly one charge and the delivery receipt is persisted. watchUniverse is the configured exact-ID universe, not the current observed set, so deletions compare correctly. Dataset input additionally requires

datasetCoverage: {"closed": true, "expectedItems": N}

delivery_unknown means the delivery side effect may have happened but cannot be proven from the durable receipt and exact counter delta. It is distinct from source_unavailable, never confirms payment, and is never retried automatically. If the persistent RequestQueue lock cannot be released after delivery, the confirmed receipt and counters remain truthful but OUTPUT is downgraded to delivery_unknown and the Actor fails with a nonzero process state instead of exiting as a clean success, even if the failure hook is unavailable. There is no live source discovery: supplied URLs are never requested. There are no nested Actor calls, browser sessions, proxies, or fuzzy product joins. Review actions carry review_required: true and not_sent: true; this Actor never sends them.

Pricing

The default Dataset item event is absent. maxTotalChargeUsd is checked before the paid write. Optional explanation mode is caller-funded BYOK and does not change deterministic facts or billing.

API and MCP

The standard Apify Actor API accepts the JSON input above. The package metadata is MCP-compatible, but this package does not claim a separate MCP server, remote tool registration, or payment endpoint.

curl -sS -X POST \
  'https://api.apify.com/v2/acts/zinin~us-map-retail-evidence/runs?waitForFinish=60' \
  -H 'Authorization: Bearer YOUR_APIFY_TOKEN' \
  -H 'Content-Type: application/json' \
  --data @input.json

Related Actors

These are links for workflow composition only. This Actor never calls them.

SEO

Canonical title: US MAP Retail Evidence | Deterministic Retail MAP Monitoring.

Meta description:

Process supplied US retail catalog evidence into exact-ID MAP, availability, baseline, and review findings without browsing or nested Actor calls.

Keywords: US MAP monitoring, minimum advertised price evidence,

retail catalog evidence