Amazon Vendor Central API: How to Get Your Sales, Inventory, and Traffic Data Out

If you pull Vendor Central reports by hand, you know the routine: open Retail Analytics, pick a report, set the date range, download, and do it all again for the next one. Sooner or later someone on the team says there's an API for that, and they're right. Before you commit engineering time to it, though, it's worth knowing what the API hands you, what getting access involves, and where its coverage stops, because the gaps decide whether building your own integration pays off. This guide walks through all of it from the brand team's side, with no code.

What the API Actually Is

The Vendor Central API is Amazon's Selling Partner API (SP-API), the same platform sellers use, with a set of operations and reports scoped to vendors. When people say "the Vendor Central API," they usually mean one of three separate systems:

1. Vendor retail analytics reports. The programmatic version of the reports you download from Retail Analytics today.
2. Retail Procurement APIs. Purchase orders and invoices for standard vendors who ship to Amazon's fulfillment centers.
3. Direct Fulfillment APIs. A separate program for drop-ship vendors who ship straight to Amazon's customers. If you aren't in that program, you can set this one aside.

Most brand teams asking about the API want the first system and eventually need the second. Each one is registered, scoped, and permissioned differently, so name the one you mean before anyone starts planning the build.

If you came from Seller Central, the platform and the registration flow will look familiar, but the vendor reports and procurement operations are their own set. Don't assume a seller-side report or workflow you relied on has a vendor equivalent.

What You Get: The Report Side

The reports side mirrors Retail Analytics. Amazon's report type list includes these vendor-only identifiers:

Each one has its own fields, granularity options, and lookback window. Our Vendor Central report definitions guide covers those details report by report, so we won't repeat them here.

What You Get: The Procurement Side

The procurement side gets less attention, but it's where POs and invoices live. Amazon publishes a Vendor Retail Procurement API family for standard vendors, available only to vendors, in the North America, Europe, and Far East regions.

• Orders. getPurchaseOrders and getPurchaseOrder retrieve PO details, getPurchaseOrdersStatus checks where POs stand, and submitAcknowledgement accepts or rejects a PO for fulfillment. You need at least one of two roles to call these: Amazon Fulfillment or Inventory and Order Tracking.
• Invoices and credit notes. submitInvoices sends invoices for shipped items, and a separate operation, submitCreditNotes, sends credit notes for returns, pricing corrections, and allowances.

You may have read that Vendor Central runs on EDI while SP-API belongs to sellers, but that leaves out the Retail Procurement APIs. EDI and these APIs are two channels for the same category of documents: EDI sends X12 documents over AS2, SFTP, or a VAN, while the Retail Procurement APIs exchange JSON over REST. Our Amazon EDI guide covers the EDI side.

What It Takes to Get Access

The prerequisite comes first: you need an existing, active Vendor Central account to register as a developer. If you're still working toward one, start with our guide to getting invited to Amazon Vendor Central.

With an account in place, Amazon's sequence looks like this:

1. Register as a developer. This has to be done by the primary account user on the Vendor Central account.
2. Register an application in the Solution Provider Portal.
3. Choose private or public. A private application is self-authorized and limited to your own organization. A public application is authorized by other sellers or vendors through OAuth and must be listed in the Selling Partner Appstore under the Solution Provider Portal Agreement. A brand pulling its own data almost always wants private.
4. Request roles. Roles gate access to personally identifiable information and to specific sets of operations. Vendor-relevant roles include Amazon Fulfillment, Amazon Warehousing and Distribution, Brand Analytics, Direct-to-Consumer Shipping (Restricted), Finance and Accounting, and Product Listing. Ask only for the roles your use case needs.
5. Authorize the application.
6. Test in the sandbox, then move to production calls.

Treat registration as a small project with a named owner, since the primary account user has to be involved and someone needs to decide the roles list before anyone opens the portal.

What the API Will Not Give You

Some of the data vendors care about most sits outside the report and procurement surface entirely, and it's worth knowing that before you scope a build.

• Buy box ownership, third-party offers, and live listing content. None of the vendor report types covers who holds the buy box, which third-party offers are on your ASINs, or when your detail page content changes. That information lives on the public Amazon.com product page, which is why InsightLeap treats Amazon.com as its own data integration, separate from Vendor Central.
• Lost Buy Box due to price. Amazon's Retail Pricing team no longer supports the LBB (Price) metric in the vendor retail analytics report types available through SP-API, and it was dropped in the 2022 Retail Analytics relaunch. The Lost Buy Box due to price glossary entry explains what the metric measured.
• Deep history. Each report has its own lookback limit, which varies by report and granularity. So if you want two years of weekly sales, you have to start pulling now and store every file yourself. The report definitions guide lists the limits.
• Anyone else's data. SP-API is designed around your own account's data. As one integration guide puts it, it "does not expose marketplace wide or competitor data," so category benchmarks and competitor tracking have to come from somewhere else.

InsightLeap ingests Amazon Vendor Central, Amazon Advertising, and Amazon.com and puts them in one dashboard, so the reports from Vendor Central and the buy box and listing changes from the product page show up side by side without a second integration to maintain.

Build vs. Buy

Build it yourself if all of these are true:

• You have engineers who can own an integration long term, including credential upkeep.
• What you need fits inside the reports and procurement surface above.
• You're prepared to store every pull yourself to build up history.

Buy a tool, or skip the API entirely, if any of these are true:

• You need buy box, third-party offer, or listing content monitoring, which no registration on this API will give you.
• You need history that goes back further than each report's lookback window allows.
• You'd rather not carry a developer registration and roles request for a handful of internal dashboards.

If you do build, have three things ready before you request access: a live Vendor Central account with its primary user available, a decision on a private or public application, and a short list of the roles you need. Once it's running, you can expect sales, traffic, inventory, forecasting, Net PPM, and PO data for your own account, going back as far as each report's window allows.