Amazon Vendor Central API Documentation: SP-API Guide, Authentication, and Vendor-Specific Endpoints
SP-API replaced MWS in 2024. Learn Vendor Central's LWA OAuth 2.0 auth, the 3 vendor-specific API sections that matter, and PO acknowledgment SLA design.
Table of contents
TL;DR — Key takeaways
-
Amazon replaced its legacy MWS (Marketplace Web Services) API with the Selling Partner API (SP-API) — Vendor Central integrations use the same SP-API framework as Seller Central, with vendor-specific API sections covering purchase orders, inventory acknowledgments, retail procurement, and shipment confirmations
-
SP-API authentication uses Login with Amazon (LWA) OAuth 2.0, not the old access key/secret key model — new integrations should implement the LWA token exchange pattern; MWS credentials stopped working for most endpoints after January 2024
-
The three vendor SP-API sections with the most practical impact are: Vendor Orders (receiving and acknowledging POs), Vendor Shipments (ASNs and invoice routing), and Vendor Inventory (submitting inventory feeds to Amazon’s system)
-
Amazon’s SP-API sandbox environment uses static mock responses, not live data — it’s suitable for connection testing and authentication flow validation, but not for end-to-end workflow testing with realistic data patterns
-
The most common SP-API integration failure for vendors is PO acknowledgment latency — Amazon’s SLA for PO acknowledgment is typically 24-48 hours, and missing this window triggers auto-cancel workflows that affect fill rate metrics and vendor scorecard
Amazon’s Vendor Central API documentation is one of those things that sounds straightforward until you’re actually building an integration. The documentation exists, it’s reasonably complete, but navigating the transition from MWS to SP-API, understanding vendor-specific endpoints versus seller endpoints, and knowing which APIs actually matter for the workflows you’re trying to automate requires more context than the docs themselves provide.
This guide covers the SP-API structure for Vendor Central integrations specifically — what’s available, how authentication works, the vendor-specific API sections you’ll actually use, and the integration patterns that matter for operational efficiency.
Table of Contents
-
Vendor Orders API — the integration that affects your scorecard
-
Common integration failures and how to avoid them
- Where is the Amazon Vendor Central API documentation?
- Is Amazon Vendor Central API the same as Seller Central API?
- How do I authenticate with the Amazon Vendor Central SP-API?
- What is the PO acknowledgment SLA for the Vendor Orders API?
- Does the SP-API sandbox work for Vendor Central testing?
- Vendor Central integrations that work in production, not just in the sandbox
-
Amazon Vendor Central API in 2025-2026: What Actually Changed
- Amazon migrated the remaining Vendor Central feeds to SP-API during 2025, formally deprecating MWS for Vendor use cases.
- New SP-API endpoints for Vendor purchase order confirmations and forecast feedback shipped through 2025-2026, closing functional gaps that forced teams back to the Vendor Central UI.
- LWA (Login with Amazon) token policies tightened in 2025: refresh-token lifetimes and role restrictions changed, breaking several integrations that assumed perpetual tokens.
- SP-API rate limits for Vendor endpoints were republished with per-region quotas in 2025, requiring integrators to re-tune their throttling logic.
MWS is dead — SP-API is the platform
If you’re working from older documentation or internal integration code, the first thing to know: Amazon deprecated MWS (Marketplace Web Services) and replaced it entirely with the Selling Partner API (SP-API). Amazon completed the MWS sunset in January 2024 — any integrations still using MWS access keys need to be migrated to SP-API’s LWA OAuth 2.0 authentication model.
SP-API documentation lives at developer-docs.amazon.com/sp-api/. The developer console for registering applications and managing credentials is at sellercentral.amazon.com/developer/applications (yes, it’s Seller Central — Vendor Central doesn’t have its own developer portal, which confuses most people building Vendor Central integrations for the first time).
The SP-API covers both Seller Central and Vendor Central workflows through the same API framework, with different endpoint sections and access scopes depending on account type. A hybrid 1P/3P account can hold both Vendor Central and Seller Central OAuth tokens and access both sets of endpoints from a single application registration.
2024
Year Amazon completed the MWS sunset — any Vendor Central integrations still using MWS access key authentication need to be migrated to SP-API LWA OAuth 2.0 immediately
Source: Amazon SP-API Developer Documentation
SP-API authentication for Vendor Central integrations
Epinium data
In 5+ years supporting brands on Amazon, accounts with structured content governance (NerveOps™) outperform unmanaged accounts by 2.3x on indexed keywords.
SP-API uses Login with Amazon (LWA) OAuth 2.0. The authentication flow is:
1. Application registration. Register your application in the developer console at Seller Central. You’ll receive a Client ID and Client Secret. For Vendor Central access, you need to specify the appropriate vendor scopes during registration.
2. Authorization flow. For Vendor Central, you authorize the application through the Vendor Central interface (not Seller Central). The authorization URL pattern for Vendor Central is: https://vendorcentral.amazon.com/apps/authorize/consent?application_id={app_id}&state={state}&version=beta
3. Token exchange. Exchange the authorization code for an access token and refresh token via LWA: POST to https://api.amazon.com/auth/o2/token with grant_type=authorization_code and your client credentials.
4. Token refresh. Access tokens expire after 1 hour. Use the refresh token with grant_type=refresh_token to obtain a new access token. Implement token refresh logic in your integration layer — don’t hardcode access tokens.
5. Request signing. SP-API requests require AWS Signature Version 4 signing using the Restricted Data Token (RDT) or standard LWA access token depending on the endpoint. Restricted Data Token is required for endpoints returning PII (customer data) — most vendor procurement endpoints do not require RDT.
The vendor-specific SP-API sections that matter
| API section | Key operations | SLA / operational note |
|---|---|---|
| Vendor Orders | GET purchase orders, submit PO acknowledgments | Acknowledge within 24-48h — missed ACK triggers auto-cancel |
| Vendor Shipments | Submit Advance Shipment Notices (ASNs), invoice routing | ASN required before shipment arrival — affects receiving efficiency |
| Vendor Inventory | Submit inventory feeds, warehouse availability updates | Inventory feeds inform Amazon’s replenishment algorithm |
| Retail Procurement | Purchase order management for retail procurement workflows | Used by larger vendors with dedicated retail buyer relationships |
| Catalog Items | Retrieve ASIN catalog data, product attributes | Read-only for vendors via SP-API; updates go through Vendor Central UI or feeds |
| Product Pricing | Competitive pricing data, Buy Box price information | Rate-limited; use for price intelligence rather than real-time monitoring |
FREE SESSION
Building a Vendor Central API integration? Avoid the common failure points.
Epinium has built production SP-API integrations for 200+ vendors. A 30-minute call covers your integration architecture, authentication setup, PO acknowledgment SLA design, and which vendor API endpoints are actually production-stable vs alpha.
Book technical review → ✓ Free ✓ 30 min ✓ No pitch
Vendor Orders API — the integration that affects your scorecard
The Vendor Orders API is the most operationally critical SP-API section for most vendors. Amazon generates Purchase Orders through Vendor Central and makes them available via this API. Your integration needs to:
Poll for new POs. GET /vendor/orders/v1/purchaseOrders with status=NEW returns open POs awaiting acknowledgment. Set up a polling schedule appropriate to your order volume — high-volume vendors typically poll every 15-30 minutes during business hours; lower-volume vendors can use hourly polling.
Acknowledge within the SLA window. Submit acknowledgments via POST /vendor/orders/v1/acknowledgements. The payload specifies the PO number, acknowledged quantity per line item, and item condition. Partial acknowledgments are supported — you can acknowledge partial quantities and flag specific line items as backordered. The critical operational detail: if you miss the acknowledgment window (typically 24-48 hours after PO creation), Amazon may auto-cancel the PO and this affects your on-time acknowledgment rate on the Vendor scorecard.
Handle the response correctly. The acknowledgment API returns a transactionId, not a synchronous success/failure confirmation. You need to poll the transaction status endpoint to confirm the acknowledgment was processed. Many first-time integrations mistake the transactionId response for confirmation and skip the transaction polling step — this creates silent acknowledgment failures.
Error handling for Vendor Orders deserves specific attention: Amazon’s API returns 429 (Too Many Requests) responses when rate limits are hit, and rate limits vary by endpoint and account. Implement exponential backoff with jitter, not fixed-interval retry logic. A fixed 1-second retry hitting a 5-minute rate limit window will exhaust all retry attempts immediately.
Sandbox environment — what it actually tests
SP-API provides a sandbox environment at sandbox.sellingpartnerapi-na.amazon.com (plus EU and FE variants). For Vendor Central APIs, the sandbox uses static mock responses defined in the API specification — it doesn’t generate dynamic POs, real inventory data, or realistic acknowledgment flows.
What the sandbox is useful for: authentication flow validation, request signing verification, parsing the response schema, and confirming your API client library sends correctly-formed requests. What it’s not useful for: testing end-to-end workflows with realistic timing, testing your acknowledgment SLA logic under real order volumes, or simulating error conditions that depend on state.
For more realistic integration testing, you need a staging Vendor Central account or a controlled production test with minimal real POs. Some vendors use a dedicated test marketplace (like Amazon.com.mx for US vendors) to run lower-stakes integration tests before deploying to the primary marketplace.
Common integration failures and how to avoid them
From building and reviewing vendor SP-API integrations, these are the failures we see most consistently:
No token refresh logic. LWA access tokens expire after 1 hour. Integrations that hardcode access tokens or don’t implement refresh logic silently fail after an hour of operation and require manual intervention. Implement refresh token logic on every API call — check token expiry and refresh proactively, not reactively after a 401 error.
Missing transaction status polling. As noted above, the acknowledgment and shipment confirmation endpoints return transactionIds, not direct success confirmations. Not polling transaction status creates silent failures where acknowledgments appear successful but aren’t processed.
Wrong marketplace ID. SP-API endpoints require marketplace IDs for most operations. Amazon’s marketplace IDs are documented but frequently confused: ATVPDKIKX0DER is US Amazon.com; A2EUQ1WTGCTBG2 is Amazon.ca; A1F83G8C2ARO7P is Amazon.co.uk. Using the wrong marketplace ID produces cryptic error responses.
Inadequate rate limit handling. Each SP-API endpoint has specific rate limits (requests per second and burst capacity). These are documented per endpoint in the SP-API reference. Build rate limit handling as a generic component in your API client, not endpoint-by-endpoint retry logic.
Where is the Amazon Vendor Central API documentation?
Amazon Vendor Central API documentation is part of the SP-API (Selling Partner API) documentation at developer-docs.amazon.com/sp-api/. The vendor-specific API sections are listed under the Vendors category in the left navigation. Application registration and credential management for Vendor Central integrations is done through the Seller Central developer console at sellercentral.amazon.com/developer/applications, despite being a Vendor Central integration — there is no separate Vendor Central developer portal.
Is Amazon Vendor Central API the same as Seller Central API?
They use the same SP-API framework, authentication method (LWA OAuth 2.0), and developer console. The difference is in the endpoint sections and OAuth scopes: vendor-specific endpoints cover purchase orders, shipments, inventory, and retail procurement workflows that are specific to the 1P vendor model. Seller Central endpoints cover listings, FBA inventory, orders from customers, and feedback. A hybrid 1P/3P account can access both sets of endpoints with separate authorization tokens.
How do I authenticate with the Amazon Vendor Central SP-API?
Register your application at Seller Central developer console, get Client ID and Client Secret, then authorize the application via Vendor Central’s OAuth consent flow (vendorcentral.amazon.com/apps/authorize/consent). Exchange the authorization code for access and refresh tokens via the LWA token endpoint at api.amazon.com/auth/o2/token. Access tokens expire after 1 hour — implement refresh token logic. Sign API requests using AWS Signature Version 4 with your LWA access token.
What is the PO acknowledgment SLA for the Vendor Orders API?
Amazon expects PO acknowledgment within 24-48 hours of PO creation, though the exact SLA can vary by vendor agreement. Missing the acknowledgment window triggers auto-cancel workflows on unacknowledged line items and negatively affects your on-time acknowledgment rate in the Vendor scorecard. Build your polling and acknowledgment logic with sufficient frequency (at minimum 2-3 times daily) to reliably hit this SLA window for all POs.
Does the SP-API sandbox work for Vendor Central testing?
The SP-API sandbox uses static mock responses for Vendor Central endpoints — it validates authentication and request formatting but doesn’t simulate real PO lifecycles, dynamic order volumes, or error conditions that depend on account state. For realistic integration testing, you need a staging vendor account or a controlled low-volume test against a secondary marketplace. The sandbox is most useful for initial connection verification and schema parsing, not end-to-end workflow validation.
Building a Vendor Central API integration is a different kind of project than a typical REST API integration. The stakes are operational: a failed PO acknowledgment affects your fill rate, your scorecard, and potentially your vendor relationship with Amazon. The documentation is complete but requires knowing which pieces matter for which workflows — the vendor sections are well-defined, but navigating a framework that shares infrastructure with the much-larger Seller Central ecosystem takes orientation. Getting the authentication flow right, implementing transaction status polling, and designing acknowledgment logic that reliably hits Amazon’s SLA are the three things that determine whether a vendor SP-API integration works in production or breaks quietly in the middle of the night.
TRANSFORM BY EPINIUM
Vendor Central integrations that work in production, not just in the sandbox
Epinium builds and audits SP-API vendor integrations for 200+ brands — PO acknowledgment automation, ASN submission, inventory feed management. Free technical review of your integration architecture or plan.
Free · 30 min · No commitment
Amazon Vendor Central API in 2025-2026: What Actually Changed
Amazon migrated the remaining Vendor Central feeds to SP-API during 2025, formally deprecating MWS for Vendor use cases.
What SP-API permission scopes does a Vendor Central integration actually need?
A vendor integration typically requires three scopes at minimum: Vendor Orders (to read and confirm purchase orders), Vendor Shipments (to submit ASN/advance ship notices), and Catalog Items (to retrieve ASIN-level data). If you’re also syncing invoices, add Vendor Invoices. Requesting broader scopes than you need increases your review time and raises flags during Amazon’s app review process — scope to what you actually use.
