MPSTATS API

MPSTATS API

MPSTATS is a Russian marketplace analytics platform with data on Wildberries, Ozon, and Yandex Market: product research, category analysis, seller/brand monitoring, SKU-level sales, stock, and review data.

Work through the ready-made shell scripts in scripts/ — call them via the Bash tool instead of writing HTTP code. Reference files in references/ are API contracts only.

Token setup

Scripts auto-load the token from config/.env via scripts/common.sh. A per-command MPSTATS_TOKEN env var overrides the file.

Setup and where to get the token: config/README.md.

If the token is missing, offer the user exactly 2 options before continuing:

1. User sends the token in chat → agent creates config/.env itself.
2. User runs locally: cp config/.env.example config/.env and pastes the token into config/.env.

Token page: https://mpstats.io/userpanel (API token block). Requires an active MPSTATS subscription.

References

API contracts (endpoints, params, response semantics) — read on demand:

• references/auth.md — base URL, auth headers, response codes, rate limits
• references/pagination-filter-sort.md — common request/response model for all POST endpoints
• references/wb-categories.md, references/wb-brands-sellers.md, references/wb-similar-sku.md — Wildberries
• references/ozon-categories.md, references/ozon-brands-sellers-sku.md — Ozon
• references/ym-categories.md — Yandex Market
• references/account.md — API limits
• references/coverage.md — what is wrapped by scripts vs. still uncovered
• references/presentation.md — how to format analytical answers and brand-styled HTML/PDF reports

Result formatting

Lead with a concise conclusion, then evidence. Use compact tables for multi-entity results, charts for trends/segmentation/comparisons. Don't dump raw JSON unless asked — interpret what the numbers mean for the decision. For HTML/PDF reports follow the MPSTATS brand style in references/presentation.md.

Sanity check — flag anomalies, never report blindly

MPSTATS data can contain outliers, seller errors, unit mismatches, and stale rows. Reporting them as fact misleads the user. Before presenting any number, sanity-check its magnitude.

Flag explicitly when you see:

• Price far outside the category norm — e.g. napkins at 500 000 ₽ per item, a phone case at 50 ₽, a refrigerator at 200 ₽. Compare to the category median; if it's roughly >10× off, it is almost certainly a seller-side price error, a unit mismatch (pack vs piece), or a placeholder.
• Implausible volumes — a small seller suddenly at 1 000 000 units/month; revenue without sales; revenue ≠ approximately price × units.
• Zero / null / negative values where they shouldn't be — rating 0 on a SKU with reviews, stock = -5, "0 days since last sale" on an obviously inactive SKU.
• Date / period weirdness — requested period ≠ returned period, gaps in by-date series, future-dated rows.
• Unit mismatches — price per pack treated as price per piece; m² vs piece; liters vs ml.

How to flag, in this order:

1. Show the anomalous row clearly, with the value called out (e.g. "500 000 ₽ за упаковку — похоже на ошибку ценника продавца").
2. State your best guess at the cause (unit mismatch, seller error, stale data, placeholder).
3. Either drop the row from aggregates (and say you did) or note that aggregates are skewed by it.
4. Continue the analysis on cleaned data.

Do NOT silently drop or "round" anomalies. Do NOT report them as if they were real and let the user spot the absurdity. The conclusion must rely on cleaned data; the raw outlier is mentioned for transparency.

Scripts

Ready-to-use shell scripts in scripts/. Call via the Bash tool, do not rewrite HTTP. Full catalog with per-script use-cases and routing guidance: scripts/README.md. Run any script with --help for parameters.