A data warehouse is a database where you collect, tidy and keep your numbers so that reports and tools can read from one place. Many teams build one before they build the report they actually wanted. For marketplace data, that is usually a detour.
Build already collects and stores the data for your connected accounts. Your tool asks for it with one call. This guide explains what you avoid, how to start, and when a warehouse is still the right choice.
What the detour looks like
Getting data straight from a marketplace is slow work, and most of it has nothing to do with your tool.
- Access. Each marketplace needs its own approval, and each client account needs its own authorised connection that you keep alive.
- Reports that take time. You ask for a report, wait, check if it is ready, download it and read it.
- Different shapes. Each type of ad and each kind of retail report arrives in a different format.
- Limited history. Marketplaces keep only a window of data. If you want last year, you had to start saving it last year.
- Numbers that move. Sales keep arriving for days after a click, so what you stored on Tuesday is not final until later.
- Limits. Every marketplace slows you down if you ask too often, so you need queues and retries.
What Build does instead
Build connects to the accounts you authorise in the console, collects the data on a schedule and keeps it in one shape. Amazon is live across Seller Central, Vendor Central and Amazon Ads. Walmart, Flipkart and TikTok Shop are coming soon, and they will use the same shape.
History is already there. How far back you can look depends on your plan: 90 days on Free, 12 months on Build and 3 years on Scale.
Your code makes one kind of call for every account:
curl -X POST https://api.sellermate.ai/public/v1/tools/get_campaign_performance \
-H "X-API-Key: sm_live_..." \
-H "Content-Type: application/json" \
-d '{"amazon_account_id": "...", "start_date": "2026-10-01", "end_date": "2026-10-07", "page_size": 100}'
You get campaign rows, a summary and a pagination block. Keep asking while pagination.hasMore is true.
A quick test: if your code asks for a report and then waits for it, you are building a pipeline. You do not need to.
Get started
- Sign up at build.sellermate.ai and connect your accounts in the console.
- Create a read-only API key. It starts with
sm_live_. - Ask Claude, ChatGPT or Cursor to build what you want, and paste this first.
Read the API docs at https://www.sellermate.ai/api-docs first.
Call get_user_context first to list my accounts. Then build a small
tool that shows last week's spend, sales and ACoS for each account.
Use the X-API-Key header, read the key from BUILD_API_KEY, paginate
with page_size while pagination.hasMore is true, and wait for the
Retry-After header on a 429.
Check it
Compare one account's totals with the console for the same dates. They should match. Check again if a date range includes the last few days, because sales may still be arriving.
When a warehouse still makes sense
Three cases remain.
- You join marketplace data with other sources. Shopify orders, product costs from your finance system, or Google Ads spend all need one place you control.
- Your analysts already work in BigQuery, Snowflake or Power BI. A small nightly script can call Build for each account and write the rows into one more table.
- You must keep your own copy. Some contracts and audits ask for it.
In all three, Build is the source and the warehouse is the destination. You still skip the hard part. If you have no warehouse, a Google Sheet that refreshes itself is often enough.
Watch out for
- You depend on Build for the data, and on each marketplace for the access behind it. Disconnecting an account stops billing, and the data is held for 30 days before it is deleted.
- Recent days can change as late sales arrive. Report on finished periods when it matters.
- Check key numbers against the marketplace the first time, so you trust the rest.
- Limits are 60 requests a minute on Free and Build, and 300 on Scale. Page through large reports rather than asking for everything at once.