tiresapi

Curated answer: cheapest tire listing for a size or SKU within radius of a ZIP. $0.001 per call, debited from the agent's virtual USD balance FIRST. Only when the balance reaches $0 does this 402 / x402 envelope draw from the wallet's MPP allowance — wallets are never charged while credit remains.

Curated answer: retailer stores carrying a SKU (or any inventory) near a ZIP. $0.001 per call, debited from the agent's virtual USD balance first.

Paged tire SKU catalogue dump for offline matching. Priced at $5.00 per 100 rows; `limit` is hard-capped at 100. Optional `updated_since=YYYY-MM-DD` returns only rows updated on/after that UTC date so agents can diff snapshots cheaply. Response echoes `catalogue_as_of_utc`. Empty result sets are auto-credited back to the agent's virtual balance.

Paged retailer store directory dump. Priced at $5.00 per 100 rows; `limit` is hard-capped at 100. Empty result sets are auto-credited back to the agent's virtual balance.

Per-retailer fee structure (install + disposal + shop + road-hazard + lifetime-balance + alignment) for computing drive-out (out-the-door) price from a sticker quote. Flat $0.005/call; cached 1h server-side. Returns ~33 rows; one shot per session is enough.

Latest-snapshot inventory rows (up to 200/page). Requires at least one filter (tire_size, key_brand_mpc, retailer_key, zip_code, or state); if none are on the URL, zip_code defaults to 33705 (Tampa) with radius_miles=40 so discovery probes reach a 402. For cheapest-in-radius use POST /api/v1/answers/best_price_near.

Inventory rows for a single last_extracted partition (single SKU or size).

Same-tire, same-DMA price spread report for a fixed snapshot date. National retailers (TIRERACK et al.) are folded into every DMA aggregate. Requires one of tire_size, key_brand_mpc, or dma_code. Optional min_delta_usd filter. 200 rows/page.

Same-tire price spread inside a zip+radius bounding box for a fixed snapshot date. National retailers always included. Optional min_delta_usd filter. Distances are great-circle miles from the ZIP centroid. 200 rows/page.

Inventory history walk over inventory_product_detail_history with broad optional filters (size, key_brand_mpc, retailer, state, zip+radius, date range). 200 rows/page. Empty result sets are auto-credited. Set `summary=true` for one-row-per-(tire_size, brand) aggregates (count + min/max/avg/median price + distinct retailers + date range) instead of raw per-store rows — use for severity / band analysis.

Daily price series for one SKU (key_brand_mpc) over up to 365 days.

Daily price series for one tire size over up to 365 days.

How often each (retailer, brand) carries a live promo over the last `days` (1..365, default 90). 'Promo' = `promo IS NOT NULL OR promo_json IS NOT NULL` (the two columns are populated by disjoint retailer sets; this proc unifies them). Requires at least one of retailer_key / brand / state to bound the scan.

Submit a retailer-coverage request. If we already cover the (retailer, zip) combo the row is still logged for analytics AND the $0.01 is credited back to the agent's virtual balance — so agents aren't out of pocket for a useful-but-already-served signal.

Submit a free-form data request. Always queued; the data team triages and replies out-of-band. Use for ad-hoc asks that don't fit retailer-coverage (e.g. "add support for retailer X" or "backfill historical pricing for sku Y").

SQL sandbox over guarded dbo.v_* views (SELECT-only, capped 500 rows, 90s timeout). Flat $0.020 per call. There is no dbo.v_inventory_history — history rows are dbo.v_inventory_by_day or GET /api/v1/corpus/inventory/history. Use only when no curated answer/corpus tool fits the question.