You know that feeling when a tool you've trusted for years goes quiet? That's MWS right now. Amazon's December 2025 docs say it clearly: move to SP‑API or stay stuck on legacy rails.
This isn't a nudge; it's a roadmap. The new MWS‑to‑SP‑API Migration Guide shows how to move without breaking prod. You'll also get new features, better visibility, and cleaner docs. No more digging through ancient READMEs like it's a museum.
If you've been doomscrolling 'documentation updates reddit' or refreshing 'documentation updates github' for crumbs, breathe. This guide cuts the noise and shows the path from MWS to SP‑API. Fast, safer, and with fewer WTF moments, promise.
Bottom line: if your stack touches orders, feeds, reports, pricing, or catalog, this is your sign. The route is mapped, the auth is modern, and the tooling is saner. Plan the migration, dual‑run to reduce risk, and enable notifications. Stop paying the polling tax. Future you will sleep better.
December 2025 docs add needed clarity. SP‑API isn't just 'MWS but newer.' It's a new architecture with granular permissions, standard auth with LWA and SigV4, and explicit rate limits. The refreshed guide shows endpoint mappings and scope shifts. You can plan with confidence now.
First‑hand example: if you call MWS ListOrders today, use SP‑API Orders getOrders. Authenticate with LWA and sign using SigV4. Request marketplace data via parameters. Align throttling to operation quotas, not account buckets. Same job, tighter control.
A few practical shifts you'll feel on day one:
If you've asked 'maintain documentation meaning' in Slack, here's the answer. Treat docs, code, and configs as one deployable unit. The December update leans into that with clearer migration paths. Sandbox flows and GitHub‑hosted specs help you point pull requests at the source of truth.
First‑hand example: many teams migrate catalog writes first. Think Feeds and Reports to Feeds v2021-06-30 and Reports v2021-06-30. Then they tackle Orders and Notifications. Chunk by capability, not by monolith.
References: SP‑API docs are centralized here: SP‑API docs
Use the official mapping tables, but here's a quick cheat sheet to plan:
getOrders; ListOrderItems → getOrderItemscreateFeed and createFeedDocument; GetFeedSubmissionList → getFeedscreateReport; GetReport → getReportDocumentAlways verify operation names, request and response models, and scopes in the latest docs. Do that before you ship any code.
Running on MWS in 2025 is like shipping on an old framework past LTS. Quiet until it isn't. December's docs nudge you to move now for continued support and new features. Translation: don't wait for a last call to hit peak sales.
First‑hand example: a merchant ops team waited until throttling changed during their highest‑order week. Their patch worked, but it cost a sprint and a weekend. With SP‑API, they used notifications and leaner requests. They dodged the burst entirely.
Think of a simple two‑by‑two. Do low effort, high impact items first, like Orders reads, key Reports, and Feeds. Then high effort, high impact work, like complex listing updates and multi‑region rollout. Skip nice‑to‑haves until parity is stable.
SP‑API gives operation‑level throttling guidance, consistent errors, and cleaner retry patterns. That means fewer mystery failures. With sandbox endpoints, you can simulate flows before production. You ship with less guesswork.
Docs tie‑ins:
Add a few guardrails and you'll feel the calm:
x-amzn-RequestId, you have it.If you care about 'update search' and 'seo updates,' the lesson is the same. Clear instrumentation and fresh docs speed diagnosis. Migrate now, test hard, and you'll cut mean time to recover.
Reference: Selling Partner API models and docs on GitHub: selling-partner-api-docs and selling-partner-api-models
Start with a real inventory. List MWS endpoints, data flows, schedules, and dependencies. Map each one to its SP‑API replacement and note scopes. Prioritize high‑churn or high‑value flows first. Orders, Catalog, Feeds and Reports usually pay off fastest.
First‑hand example: run a dual pipeline. Keep MWS live and stand up SP‑API beside it. Mirror a slice of traffic. Diff payloads and outcomes. When gaps are near zero for a full sales cycle, flip primary to SP‑API. Keep MWS as fallback for a short, time‑boxed window.
Make the mapping concrete with a lightweight workbook:
Community intel helps a lot. Track 'documentation updates github' for change logs and examples. Browse 'documentation updates reddit' threads for edge cases and gotchas. Use that feedback loop to harden your rollout. Do it before customers find your blind spots.
Useful references: LWA docs and AWS SigV4
A few more pragmatic tips:
Docs aren't homework. They're your team's memory. Keep docs in the repo, versioned with code. Add pull request checks for example requests, scopes, and rate‑limit notes. Each release updates both code and docs. That's how you maintain documentation in practice.
First‑hand example: create a /docs/integrations/sp-api/ path with:
Add a tiny toolchain to keep it honest:
This is where 'seo updates' stop being just marketing. Good structure, canonical links, and fresh examples make docs discoverable. Devs find the right answer the first time.
References: Google Search Central blog
Q: Is MWS still supported?
A: The December 2025 docs encourage accelerating your move to SP‑API. That ensures support and access to new features. If you rely on MWS, plan now to avoid surprises.
Q: What's the SP‑API equivalent for common MWS calls?
A: Examples: MWS ListOrders → SP‑API Orders getOrders. MWS SubmitFeed → SP‑API Feeds createFeed and createFeedDocument. MWS RequestReport → SP‑API Reports createReport and getReport. Always verify names and payloads in the official docs.
Q: Do I need new auth?
A: Yes. SP‑API uses LWA for access and refresh tokens, plus AWS Signature Version 4 for signing. You'll also request fine‑grained scopes per app.
Q: How do I test safely?
A: Use the SP‑API sandbox, then stage your rollout. Mirror non‑critical traffic, compare outputs, and promote after a stable window. Keep MWS as a short, time‑boxed fallback.
Q: What about rate limits?
A: Limits are operation specific. Use exponential backoff, respect quotas, and monitor x-amzn-RequestId and error codes. Replace polling with Notifications when possible.
Q: Where do I track documentation updates?
A: Follow the official SP‑API docs and GitHub repos for change logs. Reddit communities like r/AmazonSeller and r/aws surface edge cases fast.
Q: Do I need Restricted Data Token?
A: If you access PII or other restricted fields, yes. Request RDT to tightly scope and audit that access. It limits exposure and helps compliance reviews.
Q: How long should I dual‑run?
A: Long enough to cover a normal sales cycle and known spikes. Many teams run two to four weeks with parity metrics. End it with a scheduled cutover.
Q: What about client libraries?
A: Start with official models and OpenAPI specs from GitHub. Use or build a thin client that handles auth, retries, and logging. Keep it small so updates are painless.
Q: Any hidden gotchas on payloads?
A: Expect differences in field names, pagination, and error shapes. Normalize early in adapters and write contract tests that pin structures.
Pro tip: use this sprint as a playbook, not a cage. If Orders drives your business, do that first and win fast. If Feeds is the hardest part, front‑load it to reduce late risk.
You don't need to be first. You need to be deliberate, observable, and fast.
Wrap this up: SP‑API isn't just the new endpoint of the week. It's cleaner permissions, standard auth, and a docs ecosystem that reduces drift. The December 2025 updates make one thing obvious. Migrating now buys stability later. Treat docs like code, dual‑run to de‑risk, and listen to GitHub and Reddit. You'll spot issues early. When the next urgent update lands, your system just keeps humming.