Amazon Vendor Central API Documentation: A Developer's Map

You've been handed the ticket: get our Vendor Central data out through the API. You search for the Amazon Vendor Central API documentation and land on the Selling Partner API (SP-API) docs, which serve sellers and vendors from the same site. There is no separate vendor manual to download, so the first job is working out which parts of that site apply to a vendor account at all. This guide maps those parts for the developer doing the integration: where the vendor-relevant models sit, which ones only vendors can call, how a vendor app authenticates, and what the client library situation means if your stack is neither Java nor C#.

If you are still at the earlier question of which reports and purchase order operations the API offers, and whether your brand should build at all, start with our Vendor Central API guide. This piece picks up where that one leaves off.

You're Looking at the Wrong Docs If...

You're reading pages written for sellers and assuming they apply to you. Amazon expects this, and the SP-API welcome page carries a note aimed at vendors: "Looking for vendor content? Start with SP-API models to identify the APIs that apply to vendors, then visit the corresponding documentation and FAQ" (SP-API welcome page). The site has no vendor section of its own, so pages that apply only to vendors are marked "for vendor applications only," and the FAQ carries a set of vendor-specific questions alongside the general ones.

The models page is where the sorting happens. It's one alphabetical list of every API, and each entry carries an Availability field that reads Sellers only, Vendors only, or Sellers and Vendors, along with the current version, any legacy versions, the sandbox type, and release notes (SP-API models). There's no filter, so you read that column yourself.

Before you write any code, work through the list in this order:

1. Open the SP-API models page.
2. Skip every entry marked Sellers only.
3. Write down each Vendors only and Sellers and Vendors entry that touches your use case, with its current version string.
4. Open the API reference for each one and note which operations you need.
5. Read the vendor questions in the FAQ.
6. Check the deprecation schedule and release notes for every model on your list before you pin a version.

Watch for names that collide. The Invoices API you want as a vendor is v2026-06-25 and marked Vendors only, while the Invoices API - Brazil Only (v2024-06-19) is marked Sellers only and covers invoices for Brazilian FBA orders (SP-API models).

The Vendor-Only APIs

Beyond the Retail Procurement and Direct Fulfillment operations covered in the Vendor Central API guide, two newer models on the list are marked Vendors only (SP-API models):

• Finance Remittance API (v2026-03-17). Programmatic access to vendor payment remittance data. If your finance team reconciles Amazon payments against invoices by hand today, this is the first model to read.
• Invoices API (v2026-06-25). Amazon describes it as a way to "retrieve invoice data programmatically and streamline bookkeeping."

Both carry 2026 version strings, which makes step 6 of the checklist above especially worth doing for these two.

The Shared Models Vendors Actually Use

Most of what a vendor integration calls is marked Sellers and Vendors, and because the docs for these models are written with sellers in mind, the Availability column is your only confirmation that a vendor app can use them. Here is each one, with its current version and the reason a vendor would reach for it (SP-API models):

• Reports API (v2021-06-30). Where the vendor sales, traffic, inventory, forecasting, and Net PPM reports come from. The report types themselves are listed in the Vendor Central API guide.
• Data Kiosk API (v2023-11-15). Lets you "submit GraphQL queries for data from a variety of schemas." Plan for a GraphQL client alongside your REST client if you use it.
• Catalog Items API (v2022-04-01). Retrieves product catalog information for your ASINs.
• Replenishment API (v2022-11-07). Returns business performance information for Amazon's replenishment program.
• Feeds API (v2021-06-30). Uploads data to Amazon to manage your business.
• Notifications API (v1). Subscribes your app to notifications relevant to your business.
• Application Management API (v2023-11-30). Rotates the client secret on your registered application. Build this in from the start so a secret rotation never takes your integration down.
• A+ Content Management API (2020-11-01). Creates and edits A+ Content.
• Product Type Definitions API (v2020-09-01). Searches and retrieves the attribute and data requirements for product types.
• Customer Feedback API (2024-06-01). Retrieves "insights from customer reviews and returns."

Authenticating as a Vendor App

Every SP-API call carries a Login with Amazon (LWA) access token. You get one with a secure HTTP POST to https://api.amazon.com/auth/o2/token, sending your client_id, client_secret, and a grant_type (Connecting to the Selling Partner API). There are two grant types, and a vendor integration usually needs both:

1. refresh_token for every operation that needs authorization from the selling partner, which is every operation that is not grantless. Send the refresh token issued when the vendor account authorized your app.
2. client_credentials for grantless operations. These require a scope parameter: sellingpartnerapi::notifications for the Notifications API and sellingpartnerapi::client_credential:rotation for the Application Management API.

An LWA access token expires one hour after it is issued, so cache the token and refresh it before the hour is up, with separate handling for each grant type.

Each request to an SP-API endpoint (for example https://sellingpartnerapi-na.amazon.com) then needs three headers:

• x-amz-access-token: the LWA access token.
• x-amz-date: the date and time of your request.
• user-agent: at most 500 characters, carrying at least your app name, version, and language in the form AppId/AppVersionId (Language=LanguageNameAndVersion).

If you came from Seller Central: the token flow and headers are the same ones a seller app uses. What changes for a vendor app is which models it can call, and the Availability column on the models page is where you confirm that, one model at a time.

The SDK Gap

Amazon's selling-partner-api-models repository holds three things: the Swagger models for every current API, the JSON schemas, and prebuilt client libraries. The prebuilt clients come in two languages, Java and C#, and both include the authentication and authorization handling described above.

For any other language, including Python, Ruby, and Node, you generate the client yourself. The repository ships mustache templates for swagger-codegen under resources/swagger-codegen that add the authentication and authorization handling to the generated libraries. In practice that means:

1. Install swagger-codegen in your build environment.
2. Generate a client for each model on your list, using Amazon's templates.
3. Wrap the generated clients in your own code for token caching, retries, and logging.
4. Regenerate whenever Amazon publishes a new model version you need, and retest against the sandbox.

That fourth step recurs for the life of the integration, so check the release notes for every model you generated before each release of your own. If your stack is neither Java nor C#, put codegen and regeneration in the engineering estimate as their own line items, because they're easy to miss when the build is scoped from the business side.

What's Already Covered Elsewhere

This guide stays on the documentation itself, and two other pages cover the rest:

• The Vendor Central API guide covers the vendor report types, the Retail Procurement operations for purchase orders and invoices, the developer and app registration sequence, and what the API leaves out.
• The Vendor API glossary entry defines the term and the systems it spans.

If the integration is meant to feed an AI assistant, our piece on Vendor Central MCP options covers what exists for vendors today.

Is It Worth Building

Once you've mapped the models and seen the codegen work, the build question looks different from the engineer's chair than from the brand manager's. Build it yourself if all of these hold:

• Your stack is Java or C#, or you are willing to own a generated client and its regeneration.
• Every question the business wants answered maps to a model marked Vendors only or Sellers and Vendors.
• Someone will own the LWA credentials, the secret rotation, and the token refresh after the first release.
• You have a place to store report history, since each report has its own lookback window (Vendor Central API guide).

Look at a tool instead if the business also wants data no SP-API model returns, such as who holds the Buy Box or when your detail page content changed. InsightLeap automates Vendor Central reporting, keeps historic reports beyond what Amazon lets you see, and monitors your ASINs on Amazon.com for lost Buy Box, content changes, and suppressed listings, so your team can skip the codegen and credential upkeep.

Either way, start from the models page: make your list of vendor-available models and versions first, then estimate the work against that list.