The Marketplace Participations report is the answer to "which marketplaces does this Amazon seller account actually touch, and is it in good standing in each?" One row is one marketplace in the account's grid, and the row has three parts. The marketplace's own identity — reported_marketplace_id, marketplace_name, reported_country_code, default_currency_code, default_language_code, domain_name — describes the marketplace, not the seller. store_name is the one column about the account: the name it trades under there. The two flags, is_participating and has_suspended_listings, are the participation state.

The response is account-level. A single call returns every marketplace the credential reaches, each row naming its own marketplace, so the file is a grid rather than a per-marketplace report. The grid is whatever Amazon says the account touches, which is not the same as its storefronts: the validated production pull answered eight rows, every field present on every one, and among them were rows named "Non-Amazon" carrying an internal store domain (siprod.stores.amazon.ca) sitting beside the real marketplaces. They are often referred to as SI-store rows, after that domain. Amazon's Sellers documentation does not describe them at all — its schema defines a marketplace only as somewhere "a seller can list items and customers can view and purchase items" — and nothing on a live Amazon page expands SI, so the label is not Amazon's.

The reported_ prefix marks a column as the row's content — Amazon's answer — as opposed to the marketplace and currency the pull was run under. default_currency_code keeps the API's "default" for the same reason: it is the marketplace's currency, and it does not have to match anything about the account.

There is no date column. Participation and suspension are states that change in place, so each pull is a snapshot stamped with the day it was taken, not a day's worth of activity.

This is not a Reports API report: there is no report type to request, nothing to poll and no document to download. It comes from the Selling Partner API's Sellers API v1, from the getMarketplaceParticipations operation — a synchronous, unpaginated call that returns the whole grid in one response. Call it once per credential; across the production responses checked, the marketplace in the request only chose the regional endpoint — it did not filter the rows — and every row names its own marketplace in reported_marketplace_id. That is a measured observation rather than a documented one: Amazon documents only that a request must go to the endpoint for your target store, and says nothing about what a single response spans. So if your account sells across selling regions, check against your own credential whether a different regional endpoint answers with the same grid or a subset.

Access has been checked against production and is simple. The operation answers for sellers of every authorization vintage — it is a day-one API, and a credential whose grant predates the newer Finances API versions answers fine. It returns 403 for vendors, so this is a sellers-only report; a 403 here on a credential you believed was a seller is worth investigating before anything else.

One trap for anyone building on this table: the sibling getAccount operation, the obvious place to reach for account-level enrichment, behaves differently on both axes. In production it 403s for the same old seller credential that getMarketplaceParticipations answers without complaint, which reads as a newer operation gated by authorization vintage. Amazon documents a second reason that would produce the same 403: getAccount "is only available in the Amazon EU store", so a credential outside the EU store would be refused whatever its vintage. Either way, do not assume that because one works the other will.

Amazon publishes no refresh statement for this response, and the data has no cadence of its own: every response is the state at the moment of the call, and calling twice in an hour returns two snapshots an hour apart. How often to call it is a decision on your side. No Seller Central download produces this file, and no console route to the same grid can be cited either — Amazon's seller help hub, including the Account settings page, renders only behind a Seller Central sign-in, so the API is the only sourceable path.

Discovering the marketplace list before pulling anything else. Almost every other SP-API report is requested per marketplace, and requesting one the account does not sell in wastes a call or fails. The reported_marketplace_id column, filtered on is_participating, is the list to drive those pulls from — it comes from Amazon, not from what someone typed into a config file. Amazon defines the flag only as "the seller participates in the marketplace" and describes the response as the marketplaces where the seller can list items, so read it as Amazon's own answer rather than as a test you can restate.

Catching a status change as soon as you pull it. has_suspended_listings is an account-level state: Amazon sets it true when the store's Listings Status in that marketplace is Inactive, so diffing it between consecutive snapshots tells you the whole store went inactive there — not that one ASIN was suppressed — and it moves before a sales drop shows up anywhere. Amazon does not document what puts that status into Inactive, so treat a flip as a prompt to go look in Seller Central rather than as a diagnosis. Because the flag flips back when the status clears, the diff is the signal; the value on its own is only the state at the moment of the call.

Joining currency and language to reports that lack them. Many per-marketplace files carry a marketplace id and nothing else about the marketplace. default_currency_code and default_language_code keyed on reported_marketplace_id turn a bare id into the currency a figure is denominated in and the language a listing is written in.

Mapping ids to storefronts for people. marketplace_name, domain_name and reported_country_code are the human-readable side of a marketplace id, which is what a dashboard filter or a report header should show instead of a fourteen-character code.

Telling a seller credential from a vendor one. Because the operation answers for sellers and 403s for vendors regardless of authorization vintage, the result of this one call is a reliable test of what kind of account a credential belongs to.

It is a snapshot, not a history. The response covers no period: no date range, no date column and no event log, only the account's state at the moment of the call. If nobody kept the previous file, there is no way to learn from Amazon when a flag changed. Keep every pull if you intend to answer "since when" questions.

Not every row is a storefront. Rows named "Non-Amazon", with an internal domain_name instead of a public storefront, sit in the grid beside the real marketplaces. Counting rows to get "number of marketplaces the account sells in" overstates the answer; filter to the real storefront domains, or on is_participating, before counting.

One call returns everything. Because the response spans every marketplace the credential reaches, looping over marketplaces and calling once for each does not narrow the result — it returns the same grid again, and a naive loader ends up with duplicate rows per marketplace. Call once, then split on reported_marketplace_id.

The currency is the marketplace's, not yours. default_currency_code is what the marketplace trades in. It says nothing about the currency of the pull that produced any other report, and it should not be used as if it did.

Vendors get nothing. The operation returns 403 for vendor credentials. A pipeline that shares code between seller and vendor accounts needs to skip this report for vendors rather than retry it.

getAccount is not a free companion. Enriching this table from the Sellers API's getAccount operation fails on older seller authorizations that this operation serves perfectly well.