Most sellers reach a point where Seller Central stops being enough. You have a dozen SKUs across two marketplaces, a spreadsheet that took four hours to build last month, and a nagging sense that the numbers in it are already stale. The instinct at that stage is to automate: pull the data directly, build the dashboard yourself, own the pipeline.
That is a reasonable instinct. It is also where a lot of sellers lose a month of development time discovering which parts of an Amazon P&L can actually be automated and which parts cannot be automated by anyone, because Amazon does not hold the data.
This article maps that boundary.
What the Selling Partner API actually is
The Selling Partner API (SP-API) is Amazon’s programmatic interface for seller account data. It is what replaced the older Marketplace Web Service (MWS), and it is the same interface that every third-party analytics tool uses underneath. There is no privileged back channel; a tool integrating with your account sees what your own application would see.
SP-API is organised into functional groups. For profit work, four matter:
- Reports — settlement reports, fee previews, inventory ledgers, returns data. This is the bulk of what a P&L is built from.
- Orders — order-level detail, item prices, promotion discounts.
- Finances — financial event groups, which map charges and credits to settlement periods.
- Product Fees — estimated referral and fulfillment fees for a given price on a given ASIN.
Access requires registering an application, being approved for the relevant data roles, and handling OAuth token exchange. Financial and personally identifiable data sit behind restricted roles with additional approval steps.
The three data sources, and why you need all three
A common mistake is treating SP-API as a single source of truth. In practice a real profit figure comes from three places, and only one of them is the API.
| Source | What it gives you | What it can’t give you |
|---|---|---|
| SP-API / Seller Central reports | Sales, Amazon fees, refunds, ad spend, inventory movements, settlement timing | Anything Amazon never charged you for |
| Your own records | Unit cost, inbound freight, duties and tariffs, prep and 3PL charges, software subscriptions | Nothing — but nobody else has it either |
| Derived calculations | Allocated ad spend per SKU, landed cost per unit, contribution margin, break-even price | Comes from combining the two above |
The second row is the one that stops automation projects. Amazon has no idea what you paid your supplier, what your freight forwarder invoiced, or what your prep centre charges per unit. No API returns those numbers, and no analytics tool can infer them. They have to be entered, and they have to be kept current as costs change between purchase orders.
The parts that genuinely automate well
Some of this is straightforward once the plumbing exists:
- Amazon-side fees. Referral, fulfillment, storage, return processing and refund administration all arrive as itemised charges. They can be pulled and categorised reliably.
- Ad spend. Available through the Advertising API (a separate interface from SP-API, with its own authorisation) at campaign and, with more work, ASIN level.
- Refunds and returns. Both the refunded amount and the disposition of the returned unit are reportable.
- Inventory movement. The inventory ledger shows receipts, adjustments, removals and losses, which is what makes discrepancy detection possible.
The parts that don’t
- Cost of goods. Manual, always. The question is only how well structured the entry process is.
- Landed cost allocation. If one shipment carries four SKUs, splitting freight and duty across them is a decision, not a data field. By weight? By volume? By unit value? The choice changes reported margin per SKU.
- Settlement timing versus earning period. Amazon settles on a rolling schedule that does not align with calendar months. A charge can appear in a settlement two weeks after the order it relates to. Mapping charges back to the period in which they were actually earned or incurred is accrual logic you have to implement.
- Reimbursement attribution. A reimbursement received in March may relate to a unit lost in December. Booking it in March overstates March and leaves December permanently wrong.
Profit math: why the timing question isn’t academic
Take a SKU with the following illustrative figures over a two-month window:
- January: 400 units sold at $28, unit landed cost $11
- February: 380 units sold at $28, unit landed cost $13 (new shipment, higher freight)
If your system applies the current cost to all historical sales — a very common shortcut in home-built dashboards — January’s margin gets recalculated at $13 and quietly drops:
January gross margin, correct (FIFO): 400 × ($28 − $11) = $6,800
January gross margin, current-cost error: 400 × ($28 − $13) = $6,000
Reported understatement: $800 (11.8%)
Nothing about January changed. Only the cost method did. Scale that across a catalogue and across a rising-cost year, and the reported trend line points the wrong way — which is exactly when sellers make bad decisions about which SKUs to cut.
Build or buy: the honest comparison
The decision is rarely about whether SP-API is capable. It is about total cost of ownership.
Building makes sense when you have unusual logic no tool models — a bespoke landed-cost allocation, an internal cost system to integrate, consolidated reporting across channels that no vendor covers — and you have developer capacity that is genuinely spare.
Building tends to disappoint when the goal is simply an accurate P&L. The API surface changes, report schemas get versioned, rate limits require queueing and retry logic, token refresh breaks quietly, and Amazon introduces new fee types that your categorisation logic silently drops into “other.” The initial build is the easy part; the maintenance is the cost.
Tools like sellerboard exist on the buy side of that line: they handle the SP-API integration, fee categorisation and accrual mapping, and take cost data as an input from you — because that part cannot be sourced anywhere else.
Best practices if you’re building
- Pull settlement reports, not just order reports. Orders tell you what sold; settlements tell you what you were actually charged.
- Store raw responses. When a number looks wrong six months later, you need the original payload, not your parsed version of it.
- Version your cost data. Every unit cost needs an effective date. This single decision prevents the retroactive-margin problem above.
- Categorise fees defensively. Route unrecognised fee types to a visible bucket that raises an alert, never into a silent catch-all.
- Reconcile monthly against a settlement. If your dashboard and the settlement disagree, your dashboard is wrong.
- Respect rate limits from day one. Retrofitting a queue is harder than building one.
Common mistakes
- Treating deposits as revenue. A settlement deposit is net of fees, refunds and reserves. It is not a sales figure and not a profit figure.
- Ignoring the reserve. Amazon withholds against pending refunds. Cash flow and profit diverge here, and conflating them causes reorder mistakes.
- Allocating ad spend evenly. Dividing total ad spend by SKU count is not attribution. It makes efficient SKUs look worse and inefficient ones look better.
- Assuming the fee preview equals the fee charged. The Product Fees API returns an estimate based on current dimensions. Amazon remeasures units, and dimension changes move a SKU into a different size tier retroactively.
- Building without a reconciliation step. A dashboard nobody has checked against a settlement is a confident guess.
FAQ
Is SP-API free to use? Amazon does not charge for API access. The cost is development and maintenance time, plus any infrastructure you run.
Can I get cost of goods from Amazon? No. Amazon has no visibility into what you paid for inventory. COGS must be supplied by you, in any system.
Does SP-API give ASIN-level advertising data? Advertising data comes from the Advertising API, which is separate. ASIN-level attribution is achievable but requires combining advertised-product reports with your own logic.
How far back can I pull historical data? Report availability windows vary by report type, and some are considerably shorter than sellers expect. If historical accuracy matters, start archiving before you need it.
Do third-party tools see more than my own application would? No. They use the same interface with the same roles. What differs is the accumulated logic for interpreting the data, not the access.
Conclusion
The useful mental model is this: Amazon can tell you everything it charged you and nothing about what you spent before the unit reached them. Automation handles the first half completely and the second half not at all.
That is not a limitation of any particular tool. It is a property of the data. Sellers who understand it early stop looking for a system that will discover their costs, and start building a disciplined process for recording them — which is the part that actually determines whether the profit figure is trustworthy.
