Skip to main content
All CollectionsData SourcesAmazon
Amazon Unified, Multi-Marketplace Seller Accounts
Amazon Unified, Multi-Marketplace Seller Accounts

Unified or multi-marketplace sellers and special considerations for marketplace identification

Openbridge Support avatar
Written by Openbridge Support
Updated this week

Multi-marketplace can be a confusing topic for sellers. You can sell in multiple Amazon marketplaces, but that does not mean you are a "multi-marketplace" Amazon seller.

This article details a multi-marketplace seller and the implications for this unified seller account on Amazon APIs.

What are Amazon Multi-marketplace Sellers?

Amazon has a precise definition of a unified or "multi-marketplace" seller:

  • A multi-marketplace account reflects what Amazon calls a unified seller account that reflects a standard seller ID across multiple markets.

Suppose you are in Europe (EU) or North America (NA). This means you will have a single, unified seller account and multiple MarketplaceId values associated with your seller ID. If your default market is Germany and you register with Amazon for a unified seller account, you can have various EU markets attached to this ID. In addition to DE, your seller ID will have FR, GB, IT, ES... and so forth.

Amazon "Default" Marketplaces

Per Amazon, a multi-marketplace seller will have a "default" market. A default market reflects the first market you used to register your seller account. In the above example, the seller first registered in Germany, which means it will be the default market.

Read more on this here:

How to identify multi-marketplace Seller accounts?

You can certainly log into your Amazon account to check this. However, we also provide clues on the account type in Openbridge.

In your Openbridge account, when creating or editing a pipeline, we will display the information supplied by Amazon for a given seller account. A quick way to identify a unified, multi-market account is when you see multiple countries, languages, and currencies listed. For example, in the image below, the seller has a unified, multi-market account for a number in Europe. When we collect data, the pipeline will cover all the marketplaces listed.

How multi-market accounts impact data collection and storage

In cases where a multi-marketplace seller exists, all the associated marketplaces are consolidated into one pipeline.

Since Amazon views a unified account as a grouping of markets for a seller, the data is supplied by Amazon for each market using the same authorization. As a result, you need 1 data pipeline to collect data from all marketplaces associated with that unified seller. For example, if a seller registered in DE with the UK, IT, FR, SP, ES... under a unified account, a pipeline would collect data for six marketplaces in one pipeline.

Within Openbridge, you only need to establish 1 pipeline for the unified seller account. In this regard, the outcome of a multi-marketplace account is reducing the number of pipelines required to collect data compared to a seller who individually registered each marketplace (i.e., a non-unified account).

Understanding Seller and Marketplace Identifiers

Openbridge, not Amazon, sets two data elements across all Amazon feeds to help you understand what seller and marketplace a record is linked to. These elements are *seller_id and *marketplace_id.

Why does Openbridge do this? Amazon does not supply a seller or market identifier in its API outputs at a record level, so we insert them as part of the data pipeline process. These elements provide a unique set of data points to filter your queries.

However, for multi-marketplace sellers, Amazon will return the same (or similar) data for multiple markets. The result of this behavior is that there are cases where the marketplace id may not be sufficient. Even Amazon acknowledges these cases as they will state you will need to use columns like the "sales_channel" to know if a row belongs to a specific market.

How Amazon Supplies Data

Openbridge does not know if a seller is multi-market. We will call Seller API, and Amazon will return a seller's marketplace ID(s). If you are a North America (NA) multi-market seller, the response from the Seller API will list US, MX, and CA as your markets. As a result, we use these markets ( US, MX, and CA) to make API requests. Since there is no "universal" ID for all NA marketplaces, API requests are made for each marketplace ID.

However, it is not uncommon for Amazon to return the exact data for each marketplace ID. This is a quirk in its system for these account types. For example, an API request for orders using MX can return the same data as a request for the US. This means you must use other identifiers to associate a given row with a specific market.

Understanding marketplace values for unified accounts

As we mentioned, there are some unique considerations for a unified account. You will have one seller ID with multiple marketplaces vs. a unique seller ID per marketplace ID.

You'll need to expand your queries to distinguish transactions in one market from another for these unified accounts. This means being aware of how Amazon is denoting marketplaces or, in some cases, regions rather than marketplaces altogether. As a result, you can NOT rely on *marketplace_id in all cases.

Also, since Amazon may return the same data by market, it might mean you have duplicates. For example, there may be an Order ID that transaction in the US, but Amazon also returns the same ID when requesting MX. This would mean two rows; one for the US and one for MX.

Known Issues with *marketplace_id

A request to the Amazon API will include the marketplace ID. This means we are asked Amazon "Gives us X report for marketplace Y" and Amazon will return a report based on that request. We store the requested seller and marketplace IDs.

However, when we request that Amazon supply "X" data for seller ID "Y" in marketplace "Z," Amazon may not honor that marketplace ID in a request for multi-market sellers. Here is an example of the behavior https://github.com/amzn/selling-partner-api-docs/issues/1404 and https://github.com/amzn/selling-partner-api-docs/issues/2953.

As a result, we suggest deferring to channel or market identifiers like sales_channel in orders or marketplace-name in Settlements when available.

Per Amazon, to identify markets, they suggest the use of columns like the sales_channel" column to determine if an order is "Amazon UK" or "Amazon DE."

Some cases may lose data granularity (e.g., marketplace identifiers). One of those cases is the various Listings Reports. Listing Reports will only have the default seller marketplace for ob_mws_marketplace_id. This will mean that the marketplace ID will be set to the default seller market in all rows in Listings. In this case, Amazon suggests using higher-level information like "AMAZON_NA" for the column fulfillment_channel.

Here are a few examples;

  • Finance API and Settlement Reports - when present, you must use "marketplace_name" to delineate the marketplace for a row. The marketplace_name will contain values like "Amazon.es" or "Amazon.com." You can use this value to denote the country/marketplace of a record.

  • Fulfillment Inbound Shipment - There is no direct country or marketplace for Fulfillment Inbound Shipment. Amazon supplies a fulfillment center ID in the data feed. However, Amazon only publishes a comprehensive listing of all IDs to help you understand the country, state, or city in which it resides. Amazon has a partial listing that is only in the US. You have a few options: JOIN on market data from a view called *fba_daily_inventory_master. You can also use a lookup file called match fulfillment center ID to a country, region/city. See https://docs.google.com/spreadsheets/d/1fXOKQmFvyq8DTmA-zCE9MTdlpemmCaHL5FA89Me9pvU. Lastly, while Amazon may not publish the list, you can find one on Wikipedia: https://en.wikipedia.org/wiki/List_of_Amazon_locations.

  • Orders API—Each marketplace fetches its data, and we can list multiple marketplaces. As stated, you will want to use identifiers like sales_channel and currency as cross-checks.

Did this answer your question?