Amazon Data Warehouse: How to Get Seller Central, Vendor Central and Ads Data into BigQuery

An Amazon data warehouse is one place where your Seller Central, Vendor Central and Amazon Ads data lands every day, keeps its history, and can be joined with everything else the business knows: your costs, your other channels, your forecasts. Without one, every question that crosses two Amazon reports turns into a download, a lookup and a spreadsheet that is out of date by Friday.

This guide covers why Amazon's own consoles are not enough, the three ways teams build a warehouse, the design rules that decide whether its numbers can be trusted, and how to have Seller, Vendor and Ads data queryable in BigQuery the same afternoon. Amazon facts were checked against its developer documentation on 30 October 2026.

Why Seller Central alone is not a data warehouse

Seller Central, Vendor Central and the Amazon Ads console are built to run an account, not to keep its history or to answer questions across it. Four limits push growing brands toward a warehouse:

• Amazon forgets. Ads reports cover only the last few months. Vendor inventory goes back about eight weeks in weekly detail. The vendor demand forecast exists only in its newest version. Anything you do not store, you lose.
• The joins are yours to make. Ad spend lives in the Ads console, fees in settlements, sessions in Business Reports, cost of goods in your ERP. Profit per SKU needs all four on one row.
• Accounts multiply. Several marketplaces, a second brand, a vendor account next to a seller account. Each one is a separate login with separate exports.
• Teams need the same number. When finance, PPC and the category team each build their own spreadsheet, the weekly meeting turns into a debate about whose sales figure is right.

Three ways to build an Amazon data warehouse

1. Build it on Amazon's APIs

Seller and Vendor data come from the Selling Partner API, advertising data from the Amazon Ads API. Most of what matters arrives as reports: you request one, poll until Amazon has built it, download a file and parse it. Personal data such as buyer addresses needs a restricted data token and Amazon's approval for that role. Every report has its own quotas, delays and quirks.

The bigger cost is that Amazon keeps changing the ground under you. Two examples from this autumn: Amazon removes the XML and original flat-file settlement reports on 11 November 2026, and the Orders API v0 has to be replaced by version 2026-01-01 by 27 March 2027. A home-grown pipeline needs an engineer who watches the changelog.

Building fits teams with data engineers and unusual needs. Expect months, not weeks, before the numbers reconcile. If you go this way, the developers at Deltologic have built SP-API integrations since 2020.

2. Copy raw reports with a connector

A generic ETL connector copies Amazon reports into your warehouse as raw tables. That removes the plumbing, but not the modelling. Someone still has to decide which of the overlapping reports is the source of truth for sales, how settlement lines map to SKUs, how Sponsored Brands spend gets split across products, and how to stop vendor manufacturing and sourcing rows from being counted twice. Those decisions are where most of the work, and most of the mistakes, live.

3. Share a modelled data layer into your warehouse

The third route is to subscribe to tables that are already joined and documented: one schema for Seller Central, Vendor Central and Ads, with profit per SKU already calculated from orders, fees, ad spend and your COGS. Your analysts start from questions, not from parsing.

This is how DataDoe works. It fetches 130+ tables from the Selling Partner API and the Amazon Ads API, keeps them up to date, and shares them into BigQuery. The same tables answer through MCP in Claude, ChatGPT and other AI clients, and through a REST API.

In short:

• Build on the APIs: you own the plumbing, the modelling and every Amazon API change. Anything is possible, and the first trustworthy query is months away.
• Raw connector: the vendor owns the plumbing and the API changes; you still own the modelling. Days to the first table, then the real work starts.
• Modelled data layer: the vendor owns plumbing, modelling and API changes, documented per table; your own logic goes on top in SQL. The first query runs the same day.

Design rules that keep the numbers honest

Whichever route you take, these rules decide whether the warehouse is trusted or quietly ignored.

• Fix the grain of every table. One row per marketplace, account, SKU and day is the usual base for seller profit. Know what a row means before you sum it.
• Store snapshots as snapshots. Inventory, open purchase orders and forecasts describe a moment. Key them by the date you captured them and never add them across days.
• Respect time zones. Amazon dates sales in the marketplace's local time; ads data follows the advertising profile's time zone. Mixing them shifts revenue across midnight and breaks daily ACoS.
• Keep currencies apart. A UK and a US marketplace in one SUM is a meaningless number. Group by currency or convert with a dated rate.
• Expect restatements. Amazon revises traffic and buy box figures for days and weeks after the fact, and ad attribution settles late. Reload a trailing window every day instead of appending once.
• Never add overlapping views. Vendor manufacturing and sourcing figures describe the same sales from two angles. Our guide to Amazon Vendor Central reports explains which view answers which question.

Amazon data in BigQuery in an afternoon

DataDoe shares data into BigQuery through a private Google Analytics Hub listing. The steps:

1. In DataDoe, open Integrations, choose BigQuery and create an integration. Pick Integrated data (the modelled tables) or Raw data, and list the Google accounts that may access it.
2. Open the integration URL while signed in to Google Cloud with one of those accounts, and subscribe. Choose your project and a name for the linked dataset.
3. Pick the us-east4 region for the linked dataset, where the shared data lives. A project can hold datasets in other regions next to it.
4. Query. The linked dataset is read-only and is not a copy, so there is no load job to schedule and nothing to keep in sync.

The subscribing account needs the BigQuery User role in the destination project. On the Base plan there is no monthly integration fee; queries draw on the plan's AI tokens, and Google bills the BigQuery compute to your own Cloud account as usual.

A first query shows the point of a modelled table. Weekly sales, ad spend, TACoS and profit by parent ASIN, from one table, with no joins:

SELECT
  DATE_TRUNC(date, WEEK(SUNDAY)) AS week,
  marketplace_country_code,
  currency,
  parent_asin,
  SUM(total_sales) AS sales,
  SUM(ad_spend) AS ad_spend,
  SAFE_DIVIDE(SUM(ad_spend), SUM(total_sales)) AS tacos,
  SUM(profit) AS profit
FROM `your-project.your_dataset.amazon_profit_by_sku_and_date`
WHERE date >= DATE_SUB(CURRENT_DATE(), INTERVAL 12 WEEK)
GROUP BY week, marketplace_country_code, currency, parent_asin
ORDER BY week DESC, ad_spend DESC;

Profit there already includes Amazon fees, refunds, your uploaded COGS and allocated Sponsored Products, Sponsored Brands, Sponsored Display and DSP spend. The table documents how each allocation is made, so an analyst can check the method instead of trusting a black box.

Point an AI at the warehouse

A warehouse is only as useful as the questions people actually ask it. Two ways to lower the bar:

• MCP Toolbox for Databases lets an AI assistant query the linked BigQuery dataset directly, next to your own tables, once local Google Cloud credentials are set up.
• DataDoe's MCP server answers from the same Amazon tables without SQL. A PPC manager can ask Claude which campaigns lost money last week after fees and COGS, without opening BigQuery at all.

Both read the same tables, so a number in a finance model and a number in a chat answer come from one source.

Warehouse or dashboard tool?

Not every seller needs a warehouse. If the questions are always the same, a profit dashboard may be enough; we compare that approach in DataDoe vs Sellerboard. A warehouse pays off when Amazon data has to meet other data, when several accounts or a vendor account are involved, or when the analysts want SQL rather than screens. Advertising teams in particular get more from ad data that sits next to profit; that is what our Amazon PPC software page is about.

Start with today's data

Because Amazon's ads history is short, the best day to start storing it is today. DataDoe costs $97 a month with a 14-day free trial, includes the BigQuery integration and unlimited Amazon account connections, and starts building your history from the day you connect. Connect Seller Central, Vendor Central and Amazon Ads, subscribe to the listing, and run the query above on your own numbers.