To integrate Amazon data, you pull your sales, fees, advertising, inventory and cost figures out of Seller Central and the Amazon Ads console into one place, using Amazon’s reports, the Selling Partner API (SP-API), or a tool that connects to the API for you. Then you match the sources on shared identifiers (SKU and ASIN), add the costs Amazon cannot see, and check the totals on a schedule. This guide explains what to connect, the three routes available, how to combine ad and sales data, and how to keep the result accurate.
TL;DR
- Integrate four groups of data: sales and fees, advertising, inventory, and your own costs (COGS, inbound shipping, off-Amazon ad spend).
- You have three routes: manual report downloads, a custom build on the SP-API, or a connected tool. The right one depends on your volume and technical skill.
- Standardise SKU and ASIN naming and fee categories before you build any dashboard. Messy mapping causes most wrong numbers.
- Sync daily for most businesses, and reconcile source and destination totals on a schedule.
- Protect API credentials, and expect rate limits if you build your own connection.
Table of Contents
- What Amazon data is worth integrating
- Three ways to integrate Amazon data
- How to combine advertising and sales data
- Clean and standardise before you build
- How often to sync, and how to check the numbers
- Access, security and maintenance
- Our perspective: integration should end in decisions
- Where Osellpa fits
- A practical starting plan
- FAQ
- Sources
What Amazon data is worth integrating
Most sellers start with the question “am I actually making money?” and discover that the answer sits in several different places. Amazon shows you sales in one report, fees in another, ad spend in the advertising console and stock in the inventory views. None of them knows what you paid your supplier.
A useful integration brings together four groups.
Sales, fees and net proceeds
This is the backbone: orders, units, referral and fulfilment fees, refunds and what Amazon pays out. Amazon’s own description of seller economics data in the Selling Partner API shows how these fit together: the data includes advertising spend, fees, sales and net proceeds, and can be aggregated by date and product identifier, according to AWS guidance on SP-API data. That date-and-product structure is what lets you work out profit per product rather than per account.
Advertising
Sponsored Products, Brands and Display spend, clicks, orders and attributed sales live in the Amazon Ads ecosystem, separate from your retail reports. AWS makes the point that bringing marketing data alongside retail data is what makes a complete data lake possible for analytics and visualisation, as set out in its guidance on ingesting Vendor Central and Amazon Ads data. Without this join you can see ad spend, but not what it did to total sales.
Inventory and storage
Stock levels, inbound shipments, storage fees and aged stock all affect cash and margin. If your integration ignores them, your profit figure will look better than reality, because a unit sitting in a warehouse for months is a cost you pay before it is a sale. If you sell on FBA in the UK, it is worth reading how aged inventory is charged and cleared and how to calculate your FBA headroom so your stock data feeds decisions, not just a table.
Your own costs
Amazon cannot know your cost of goods sold (COGS), your freight or the money you spend on ads outside Amazon. Amazon’s Profit Analytics lets sellers upload exactly this kind of data, including COGS, inbound shipping and off-Amazon advertising spend, to get a fuller estimate of net profit. Whatever route you choose, plan a place for these figures from day one.
Three ways to integrate Amazon data
The routes differ in effort, control and upkeep. Be honest about how much time you can give to maintenance, because that is where custom builds tend to fall down.
| Route | Best for | Effort | Main risk |
|---|---|---|---|
| Manual report downloads and spreadsheets | New or part-time sellers with a few SKUs | Low to start, rises quickly | Human error, stale data, hours each week |
| Custom build on the SP-API | Sellers with developer resource and specific reporting needs | High | Maintenance, rate limits, security |
| Connected analytics tool | Most sellers who want answers, not infrastructure | Low | Choosing a tool whose data you can verify |
Route 1: manual reports
Downloading reports from Seller Central and the advertising console works when you have a handful of products. The weakness is repetition. Every week you download, clean, match and paste, and every step is a chance to misalign a SKU or miss a refund. If you take this route, keep one master sheet with a fixed layout and never edit the downloaded files by hand.
Route 2: building on the Selling Partner API
The SP-API is Amazon’s programmatic route to your account data. The documented pattern from AWS for a custom pipeline looks like this:
- Register an application so you can receive Login with Amazon (LWA) tokens.
- Store the long-lived refresh token securely, then exchange it for short-lived access tokens when calling the API.
- Subscribe to notifications such as REPORT_PROCESSING_FINISHED so you know when a requested report is ready.
- Orchestrate the requests, then download the processed report documents.
Those steps come from AWS’s Amazon Seller and Vendor Central Data Producer guidance, which stores refresh tokens in AWS Secrets Manager. A related AWS reference design uses Step Functions and Lambda to orchestrate the reports and saves the downloaded documents in Amazon S3, with Amazon QuickSight available to visualise the combined retail and ads data.
This is a sound architecture, and it is also a real software project. You will own error handling, schema changes in reports, and ongoing credential management. For a larger business with an in-house analyst it can pay off. For a seller whose time is better spent on sourcing and listings, it usually does not.
Route 3: a connected tool
A purpose-built seller tool does the API connection, scheduling and mapping for you, and presents profit, advertising and stock views ready to use. You trade some flexibility for speed and for not maintaining code. The question to ask is whether you can trace each figure back to Amazon’s own data, which is why the checks later in this guide matter whichever route you pick.
How to combine advertising and sales data
This is the join that matters most for PPC, and the one most often done wrongly.
Account-level: TACoS
Total Advertising Cost of Sales (TACoS) divides your total ad spend by your total sales, not just ad-attributed sales. To calculate it at account level you take total spend from the advertising data and total sales from your retail sales-and-traffic reporting for the same dates. Because it uses total sales, TACoS shows whether advertising is growing the business or merely capturing sales you would have made anyway. We cover how to read it over time in our guide to checking 30 days of TACoS for ad cannibalisation.
Product-level: match on ASIN, with care
Advertising reports name the advertised ASIN, while retail sales reports often break out by child ASIN or SKU. For per-product TACoS, match the advertised ASIN to the same child ASIN in your sales data, and avoid mixing in SKU-level rows that might split one product across several lines. Decide your key once, document it, and apply it everywhere.
Respect attribution timing
Ad attribution is not instant. Orders can be credited to a click days later, so yesterday’s ACoS is provisional. Pulling advertising data daily is fine, but judge performance on a window that has settled. Our guide to auditing ads weekly and waiting 7 to 14 days for attribution explains how to set that rhythm so you do not cut a campaign on incomplete data.
Mind the wider context
Advertising numbers do not stand alone. If you lose the Buy Box, ad clicks keep costing money while conversion falls, so Buy Box status belongs in the same view as ad spend. For a broader look at why joined-up data underpins good ad decisions, see this piece on the role of data in advertising.
Clean and standardise before you build
Integration fails quietly. The pipes work, the dashboard loads, and the numbers are wrong because two sources describe the same product differently. The FBA Guys recommend a layered approach in their seller financial dashboard guide: start with source data, clean and map it, and only then automate the dashboard.
In practice, that means:
- Standardise SKU and ASIN names. One product, one SKU, one ASIN mapping. Retire duplicates and typos.
- Map fee types into stable categories. Amazon labels change and new fee lines appear. Group them into categories such as fulfilment, referral, storage and advertising so your reports do not break when a label changes.
- Map COGS by SKU. Keep a cost table keyed on SKU with the date each cost applies from, so a price change from your supplier does not rewrite history.
- Separate one-off from recurring expenses. A software subscription and a one-time photography fee should not sit in the same line.
- Include refunds, reimbursements and storage fees. These are easy to leave out and they move margin noticeably. The same guide advises accounting for them explicitly.
Do this cleaning once, properly, and the rest of the integration becomes maintenance rather than rework. If you want to see where this leads, our walkthrough of SKU profitability shows how clean cost and fee data turns into a per-product earnings figure.
How often to sync, and how to check the numbers
Choose a sync frequency that fits
For most small and medium businesses, a daily batch sync is enough. Live syncing earns its extra complexity only when immediate consistency is critical, for example when stock decisions are made hour by hour. That is the guidance in this UK accountancy explainer on real-time data sync, written about financial data generally rather than Amazon alone, but the logic applies. It also recommends comparing source and destination totals each day.
Build a simple verification routine
Move from “set it and forget it” to “trust but verify”. A routine that takes five minutes a day beats a quarterly clean-up:
- Check the sync ran. Look for a last-updated time, and treat a gap as a fault.
- Compare totals. Match yesterday’s orders and units in your integrated view with Seller Central for the same period.
- Spot-check one SKU. Trace its sales, fees and ad spend from source to dashboard.
- Set a tolerance. Decide what difference is acceptable (rounding, timing) and what triggers investigation.
- Review monthly against payouts. Reconcile your net figure to what Amazon actually paid you.
The idea of defined tolerance levels and scheduled automated checks comes from a general guide to data reconciliation across systems, and it transfers neatly to seller data. Pick one canonical source of truth for each figure, usually Amazon’s own reports, and treat everything else as derived.
Access, security and maintenance
If you build your own connection, you are handling credentials that can read your sales and financial data. Take that seriously.
- Protect refresh tokens. AWS’s data producer guidance stores LWA refresh tokens in AWS Secrets Manager rather than in code or spreadsheets.
- Limit permissions. The same guidance uses IAM with defined access permissions for API calls, and KMS to encrypt data.
- Plan for rate limits. SP-API calls are rate-limited, so the guidance uses an API client to manage them. Do not fire requests blindly in a loop.
- Keep a named owner. Someone must be responsible for renewing access, watching for failed jobs and updating mappings when Amazon changes a report.
- Grant least access to people, too. Give team members and tools only the Seller Central permissions they need, and remove access when someone leaves.
With a connected tool, much of this moves to the provider, but you still control which permissions you grant, so review them occasionally.
Our perspective: integration should end in decisions
We see the same pattern with sellers of every size. They spend weeks connecting data, then end up with a dashboard nobody trusts because one number never matched Seller Central. Our view is simple: accuracy first, automation second, and neither is worth much unless it changes what you do on Monday morning.
That is why we built Osellpa around Amazon’s API rather than around exported spreadsheets. When profit, PPC, inventory and alerts draw on the same connected data, you stop reconciling five files and start asking better questions: which SKUs lose money after fees and ads, which campaigns waste spend, which products are heading for aged-stock charges. The aim is for new and part-time sellers to get accurate profit tracking without a data project, and for larger sellers to automate PPC management without hiring an analyst. Some users report sales increases of up to 20% after adopting the tools, though results depend on the account.
Our advice, whichever route you take: start with one question you need answered, such as true profit per SKU, integrate only the data that answers it, verify it daily for two weeks, and then expand.
— Harry
Where Osellpa fits
If you would rather not build and maintain a pipeline, Osellpa connects to Amazon’s API and brings profit tracking, PPC optimisation, inventory management and listing tools into one place. Plans are priced by seller size: Launch is £10 per month (£96 per year), Scale is £20 per month (£192 per year) and Advanced is £40 per month (£384 per year). You can compare them on the Osellpa pricing page, or see the full toolkit on osellpa.com.
A practical starting plan
If you are unsure where to begin, work through this order:
- List your questions. Profit per SKU? Ad efficiency? Stock risk? Write down the three that matter most.
- Inventory your sources. Seller Central reports, advertising console, supplier invoices, off-Amazon ad accounts.
- Fix your identifiers. Clean SKU and ASIN lists and a COGS table.
- Pick a route. Manual for a very small catalogue, custom only if you have developers, a connected tool for most others.
- Verify for two weeks. Run the daily checks before you rely on the figures.
- Automate the response. Once the data is trusted, automate alerts and PPC rules, then keep a weekly review. If replenishment is the pressure point, see how to automate replenishment without letting FBA fees eat margins.
FAQ
Do I need the Selling Partner API to integrate Amazon data?
No. You can download reports from Seller Central and the advertising console and combine them by hand. The API becomes worthwhile when the volume of data or the frequency of updates makes manual work slow and error-prone. Many sellers reach it through a connected tool instead of coding it themselves.
What data does Amazon not give me that I must add myself?
Your cost of goods, inbound shipping and any advertising you run off Amazon. Amazon’s Profit Analytics accepts uploaded cost data of this kind for a fuller net profit estimate. Whatever tool you use, keep these costs keyed by SKU and dated.
How often should Amazon data sync?
Daily is enough for most small and medium sellers. Choose near-live syncing only when decisions genuinely depend on up-to-the-minute figures. Either way, compare your integrated totals with Seller Central regularly.
How do I link ad spend to product profit?
Match the advertised ASIN in your ad data to the same child ASIN in your sales data, then subtract ad spend alongside fees and COGS. Use consistent SKU and ASIN mapping and allow for attribution delay before judging results.
Sources
- See What’s Driving Your Amazon Profitability (Amazon Profit Analytics)
- Data available through the Amazon Selling Partner API (AWS)
- Guidance for Ingesting Amazon Vendor Central and Amazon Ads Data on AWS
- Guidance for Amazon Seller and Vendor Central Data Producer
- Amazon Seller Financial Dashboard Setup
- How Real-Time Data Sync Ends Month-End Accounting Stress
- The Complete Guide to Data Reconciliation Across Systems
- The role of data in advertising: 2026 success guide
