The Amazon Ads Reporting API, Explained With Real Numbers

What it actually returns, and what it doesn't

There isn't one Amazon Ads reporting API — there are three, and mixing them up is the first mistake most people make. The sponsored ads reporting API (v3) covers Sponsored Products, Sponsored Brands, and Sponsored Display in one unified schema. DSP has its own separate reporting API with different fields, different report types, and different attribution logic. Amazon Marketing Cloud sits above both and works on signal-level data rather than pre-aggregated rows.

None of the three is a live dashboard. Every one of them works on an asynchronous request-poll-download model: you submit a report definition, Amazon builds it in the background, and you come back later to collect it. There is no endpoint that streams today's numbers as they happen. If a tool claims real-time Amazon Ads data, it is either polling very aggressively or rounding the truth.

Fields available include impressions, clicks, spend, attributed sales (7-day and 14-day windows depending on ad product), units sold, and new-to-brand purchases. What's absent by default: any statement about whether a sale would have happened anyway. The API tells you what happened after an ad ran. It does not tell you what happened because the ad ran — that's a different question, and it needs a different method.

The request-poll-download cycle, worked on real numbers

The mechanics: you POST a report request specifying the ad product, the reportTypeId, the columns you want, and a date range. Amazon returns a reportId with status PENDING. You poll a status endpoint until it flips to COMPLETED — this can take anywhere from a couple of minutes to over an hour depending on the size of the pull and Amazon's queue. Once complete, you get a download URL for a gzipped file, usually JSON or CSV, that you then have to parse yourself.

Here's what that looks like on an actual book of business. Across 30 advertisers we managed in July 2026, the DSP reporting pull returned 78.4 million impressions at a $4.00 CPM. Run that through the API's own numbers: 78.4 million impressions ÷ 1,000 × $4.00 CPM = roughly $313,600 in DSP spend for the period. Divide that spend by the blended cost-per-acquisition the same report showed — $5.49 — and you land on almost exactly 57,137 attributed purchases, which is the actual purchase count the report returned. The numbers reconcile because they're rows from the same pull, not separate claims stitched together.

That same portfolio ran a blended $1.42 cost-per-click — worth flagging because the $0.41 CPC figure that gets quoted constantly in this category is an online-video-only number, not a whole-book average. If your API pull returns a blended CPC nowhere near $0.41, your numbers aren't wrong. The comparison you're making them against was never the same metric.

Where the numbers disagree with each other, and why

Pull sponsored ads data and DSP data separately and add the sales together, and you will overstate performance. If a shopper sees a DSP display ad and later clicks a Sponsored Products ad for the same product, both reports can claim the sale under their own attribution window. Neither report is lying — they're just not built to talk to each other.

This is the actual reason Amazon Marketing Cloud exists. AMC works on signal-level, deduplicated data across DSP and sponsored ads, so a purchase gets counted once, not once per channel that touched it. Without that reconciliation step, any cross-channel ROAS number built by summing separate API pulls is inflated by an unknown amount — and it's usually inflated most for advertisers running both DSP and sponsored ads hard at the same time, which is exactly when the incremental question matters most.

Last-click attribution, which is what both sponsored ads and DSP reports default to, has the same structural limit: it can tell you which touchpoint came last, not whether the sale would have happened without it. That's not a reporting bug to fix with a different column. It's a question the reporting API was never built to answer — you need holdouts or matched controls for that, not a different report type.

The mistakes people make with this API — including ones we've made

Pulling a report the same day a campaign ran and treating the sales figure as final is the most common one. Amazon's attribution windows mean a purchase can attach to an ad click up to 14 days later, and reports restate as that window closes. Read a report on day one and you will see a lower number than the same report pulled on day ten. That's not a data error — it's the window doing its job.

• Timezone mismatches: reports are built in the advertiser's account timezone, not UTC. A date range boundary that looks off by a day is usually this.
• Comparing sponsored ads spend to DSP spend as if they're the same unit of currency: they're priced and auctioned differently; a blended average across both without labeling which is which misleads whoever reads it next.
• Assuming a completed report status means finished data: COMPLETED means the file is ready to download, not that every attributed sale has landed yet.
• Filtering out paused campaigns by habit: a campaign paused mid-month still has spend and sales rows for the days it ran; excluding it by default understates total spend.

We've made the restatement mistake ourselves early on — reporting a week-one ROAS number to a client as final when it was going to move for another ten days as attribution caught up. The fix wasn't a better dashboard. It was agreeing up front on which day of the reporting cycle counts as the reporting date.

When the number looks wrong, check these before you assume the API is broken

Start with the date range, not the metric. Confirm it's rendered in the account's timezone and that you're comparing like periods — a 30-day pull against a 31-day pull will never match. Then check the report status field directly rather than trusting a cached download; a stale file from an earlier poll is a common source of numbers that look frozen.

Next, confirm which report type and ad product the columns actually belong to. A metric named identically across Sponsored Products and Sponsored Display can carry different attribution logic underneath. Pull one day's numbers from the ads console by hand and compare them line by line against the API output for that same day — if they match there, the API isn't the problem, and something changed after the pull (a filter, a currency conversion, a rollup step) is.

If the numbers still don't reconcile after that, the honest answer is usually double counting across DSP and sponsored ads, not a broken API call. That's a reconciliation problem, and it needs a reconciliation tool — not a different set of report parameters.

Where reMKTR fits into this

reMKTR runs Amazon DSP as a managed service and reconciles every book in Amazon Marketing Cloud specifically to stop DSP and sponsored ads from double-counting each other — the API problem described above, solved the only way it actually gets solved. We hold real DSP seats across 109 live advertisers, and the numbers used in the worked example in this piece — the 78.4 million impressions, the $5.49 blended CPA, the $1.42 blended CPC — come from that book, not a vendor deck. reMKTR is part of the Full Circle group, which has managed more than $500M in Amazon spend across 100+ brands, working with names including HexClad, Ridge, BK Beauty, Beardbrand, Epic Gardening, The Woobles, and Walkize. None of that changes what the Reporting API can and can't tell you on its own — it just means someone downstream of the API is already doing the reconciliation this page describes.