Pulse x reMKTR

Amazon SP-API Deprecations You Must Tackle Before 2026

Written by Jacob Heinz | Dec 23, 2025 4:23:05 PM

You don’t want another fire drill in Q4, or on some random Tuesday at 2 a.m. But ignore Amazon’s SP-API deprecations, and that’s what you’ll get. Calls keep working… until they don’t. Then orders fail, inventory gets stuck, and your team scrambles.

Here’s what most folks miss: deprecated resources aren’t optional. They’re a fuse. Amazon already lit it—some deadlines passed, others barreling toward 2025, and the rest will bite in 2026 if you coast.

The fix is simple: map what breaks, move to modern endpoints, test like a paranoid SRE, and match your releases to Amazon’s monthly updates. Do that, and you’ll ship faster, cut failures, and sleep better.

Bold claim? Sure. But since the MWS sunset, Amazon’s been clear: evolve or get paged. Let’s keep you on the right side of that.

If you’re thinking, “we’re fine, it still works,” that’s the trap. Deprecated endpoints are like cards with an expiration date. They swipe… until they suddenly don’t. A little planning now beats a panicked rollback later. Let’s turn a surprise outage into a boring, predictable release.

TL;DR

  • Amazon SP-API is deprecating legacy resources on rolling timelines; after removal, calls fail outright.
  • Prioritize migrations for Listings Items, Catalog Items, Notifications (v2 payloads), and Solution Provider Portal.
  • Implement Restricted Data Tokens (RDT) for PII-sensitive operations; test in sandbox before prod.
  • Track the monthly SP-API changelog; plan releases like “Patch Tuesday.”
  • Amazon Ads API: migrate impression-generating campaigns before Amazon auto-migrates by Dec 31, 2025.

What’s Changing Now

Deadlines That Trigger Outages

Amazon’s stance is very clear. The docs say, “Calls to deprecated SP-API resources will continue to be successful until their removal date. After the removal date, calls will fail.” Translation: there’s no friendly grace period coming.

Key items:

  • Fulfillment Inbound v0 feed-style operations (e.g., POSTFLATFILELISTINGSDATA, POSTPRODUCTPRICING_DATA) were deprecated Mar 27, 2024 and scheduled for removal by Dec 20, 2024. If you still rely on feed-based product/pricing updates, prioritize Listings Items and Catalog Items APIs immediately.
  • Notifications: LISTINGITEMISSUES_CHANGE payload v1.0 was deprecated Feb 28, 2024, removed Sep 25, 2024. Upgrade to v2 to keep real-time issue alerts.
  • Solution Provider Portal migration: all SP-API developers must migrate by Aug 31, 2025. This consolidates app management, auth, and scaling. Miss it and expect access headaches.
  • Amazon Ads API: migrate impression-generating campaigns by Sep 30, 2025 or expect forced auto-migration by Dec 31, 2025.

Why this matters

  • Listing changes won’t push, pricing will stall, and stock won’t sync. That cascades into buy box losses and canceled orders—especially painful in holidays.
  • Compliance signals depend on Notifications. Lose those, and you’ll miss listing errors and policy issues.
  • Portal migration centralizes your developer footprint. If you manage multiple marketplaces or roles, this reduces auth sprawl.

Expert note: Amazon’s changelog cadence is monthly, so anchor your engineering calendar to it. Treat it like Microsoft’s Patch Tuesday—predictable, plannable, non-negotiable.

Verify Your Risk

  • Pull a 90-day log sample of outbound calls. Look for any feed submissions or endpoints flagged as “deprecated” in the official deprecations page.
  • Map each legacy call to its modern replacement: feeds → Listings Items and Catalog Items; old Notifications payloads → v2; any PII access → Tokens API + RDT.
  • Cross-check with the SP-API Changelog for breaking notes or removal dates. If a removal date is past or within a quarter, escalate to Priority 1.
  • Open a tracker per migration: owner, deadline, rollback plan, and test cases. You’re not replacing “an API”—you’re replacing business-critical workflows.

Migration Map

Catalog and Listings

If you’re still on v0 feed workflows, you’re building on sand. Move to:

  • Listings Items API v2021-08-01 for create/update inventory, quantities, and pricing
  • Catalog Items API for item details and offers

This shift unlocks granular updates, better checks, and fewer silent failures. As Amazon’s guidance says, “Adopt modern endpoints … for robust inventory control” and “enhance authorization … for PII-protected calls.”

Expert quote: “Flat files mask errors. The Listings Items API surfaces them. You’ll fix more issues before they hit buyers.” — senior marketplace engineer, large aggregator

Practical mapping tips:

  • Prices: start with a thin slice—migrate price updates via Listings Items PATCH to reduce payload size. Validate currency codes and confirm the marketplaceId on each request.
  • Quantities and fulfillment latency: move inventory quantities and lead-times next. Keep payloads minimal to isolate failures quickly.
  • Attributes/content: handle last. Content updates are noisy; run them after your SKU-level price/quantity flows are solid.
  • Idempotency: include an idempotency key on writes where supported, so retries don’t double-apply changes.

Validation checklist:

  • Confirm each SKU’s latest version/ETag if the API requires it, to avoid 409 conflicts.
  • For multi-marketplace sellers, test a representative SKU in each region—edge-case attributes differ by locale.
  • Compare pre/post update effects with live read-backs (GET) to confirm your changes stuck and didn’t trigger unintended suppressions.

Notifications Upgrade

If you used LISTINGITEMISSUES_CHANGE v1.0, upgrade to v2.0. You’ll keep critical signals like suppressions, image failures, or attribute conflicts. Losing these alerts slows fixes and dings performance metrics.

Notifications checklist:

  • Verify Destinations (SQS, SNS, or EventBridge) and permissions. Use a dead-letter queue to catch poison messages.
  • Subscribe to v2 payloads for listing issues and any other events you depend on (e.g., order or FBA events in your flow).
  • Implement retries with backoff. Deduplicate events using messageId or your own correlation key.
  • Alert on “suppression” or “image failure” keywords. Pipe them into your ops channel so humans see them fast.

Tokens and RDT

For operations touching PII, Amazon states, “Restricted Data Tokens (RDT) are required.” That means integrating the Tokens API, using minimum scopes, and rotating tokens with discipline. Good news: once you add RDT, audits get easier and risk drops.

Pro tip: ship migrations in thin vertical slices. Example: migrate price updates first (listings patch), then quantities (inventory), then content attributes. Each slice gets its own rollback plan.

RDT implementation steps:

  • Identify PII touchpoints: buyer info, addresses, phone numbers, or order details that include sensitive fields.
  • Update auth flow: obtain an RDT from the Tokens API only when needed, and keep it short-lived. Do not cache longer than required for a single workflow.
  • Least privilege: request only the minimum data elements required for your use case. Over-scoping risks denial and audit flags.
  • Storage and logging: never log PII or raw RDTs. Mask sensitive fields in app logs and encrypt secrets in transit and at rest.
  • Access review: schedule quarterly reviews of RDT scopes and usage. Remove scopes that aren’t used.

Ship Without Incidents

Sandbox First

Use the SP-API sandbox and test endpoints before touching live listings. Amazon’s own guidance: “Leverage SP-API’s test endpoints to validate migrations without live disruptions.” Build a lightweight harness that:

  • Replays your top 10 production workflows with synthetic data
  • Compares response schemas and error surfaces between old and new endpoints
  • Fails fast on permission or throttling errors

Add a canary release: route 1%–5% of updates through the new path. Watch metrics, then scale.

Extra test tips:

  • Rate limits: rehearse 429 scenarios. Implement exponential backoff and jitter; confirm you honor the headers that show limits and resets.
  • Idempotency and sequencing: verify that out-of-order updates don’t create stale state. Price before quantity; child before parent SKU, etc.
  • Rollback: write a one-click rollback for each slice. If error rates spike, flip back within minutes, not hours.
  • Traceability: propagate a correlation ID from request to logs and alerts. Keep sample requests and responses for faster debugging.

Monitor like an SRE

  • Track 4xx/5xx rates by operationId
  • Alert on latency spikes and throttling (x-amzn-RateLimit-Limit headers tell you plenty)
  • Log payload diffs for Listings and Catalog field-level changes

What to watch specifically:

  • 403 spikes: usually missing permissions or missing RDT for sensitive calls.
  • 409 conflicts: versioning or ETag mismatch. Implement read-modify-write patterns when needed.
  • 422 unprocessable: schema mismatch or invalid attribute. Capture the error body; surface it to the team that owns the data.
  • Throughput: watch not just request counts but “successful updates per minute” and “SKU coverage per hour.” Your ops team cares about business throughput.

Monthly Change Plan

Amazon posts monthly changelogs. Set your review to the same rhythm used in enterprise IT. If you’re wondering “when is Patch Tuesday December 2025?”—it’s the second Tuesday, December 9, 2025. November 2025’s falls on November 11. Use that cadence as a planning anchor: review SP-API changes that week, run regression tests, then ship.

Expert note: teams that stick to a predictable cadence cut incidents by avoiding random Tuesdays. That’s the point.

How to operationalize it:

  • Calendar block: 60 minutes, second Tuesday monthly. Attendees: app owner, QA, SRE, product ops.
  • One-pager: summarize changelog impact, migrations in-flight, new tests required, and go/no-go.
  • Ticket hygiene: open tasks the same day, tagged by API and marketplace. Assign an owner and a test date.
  • SLA: aim to validate changes within one week. Ship in the following sprint.

Team Roles Plan

  • Product owner: sets priority by business risk (Buy Box, holiday readiness, SLA impact).
  • Tech lead: defines the migration slices, rollout, and rollback strategies.
  • QA/Automation: builds the harness and regression packs.
  • SRE/Platform: rate-limit strategy, alerts, dashboards, and incident playbooks.

Timeline:

  • 30 days: inventory deprecated calls, map to modern endpoints, spin up sandbox harness, and finish the first canary (prices or quantities).
  • 60 days: migrate the rest of Listings and Catalog flows; enable v2 Notifications; add alerts and dashboards.
  • 90 days: RDT across all PII flows; Portal migration plan approved; monthly changelog rhythm established.

The Next Year

Solution Provider Portal

“All existing SP-API developers must migrate to the Solution Provider Portal by August 31, 2025.” This isn’t cosmetic. Expect consolidated app management, cleaner auth flows, and more scalable org-level controls. If you manage many regions, the Portal cuts key sprawl and permission drift.

Expert quote: “We pulled three apps into the Portal and cut onboarding time for new markets from weeks to days.” — principal engineer, cross-border seller

Migration checklist:

  • Confirm organization ownership and roles in the new Portal.
  • Recreate app configs (redirect URIs, scopes) and rotate secrets.
  • Validate LWA auth flows in a lower environment before moving prod apps.
  • Audit developers and roles; remove unused access and stale keys.
  • Update internal runbooks and incident docs with new URLs and procedures.

Amazon Ads API

If you run impression-generating campaigns via API, migrate by September 30, 2025. Otherwise, Amazon will auto-migrate you by December 31, 2025. Your QA window is better than Amazon’s automatic fallback—own it before year-end freeze. If this touches your upper-funnel mix or DSP workflows, our team’s DSP Services can help plan and validate the migration without losing reach or frequency.

Recommended approach:

  • Create a copy of top campaigns in a staging profile and validate metrics tracking.
  • Run a split test: 10% budget to migrated objects for two weeks. Watch pacing, reach, and frequency.
  • Freeze changes during cutover day; verify creatives, audiences, and placements before resuming normal ops.

AWS Partner Central

Partner Central pushed new verification, benefits, and selling features and retired older endpoints/sandboxes. If you integrate leads, opportunities, and Marketplace offers across AWS + Amazon retail, confirm endpoint names, required parameters (catalog), and sandbox availability. Breaking changes in supporting systems are how “random” outages sneak in.

Bottom line: 2025 is a consolidation year. Get your house in order before 2026 turns steady changes into emergency work.

Common Pitfalls

Staying On Feeds

Problem: flat-file feeds like POSTFLATFILELISTINGSDATA are past-due. After removal dates, calls fail. Even before, they hide errors and slow feedback.

Fix: move to Listings Items API v2021-08-01. Use partial updates (PATCH) to reduce payload size and error scope. Validate schemas in CI.

Pro move: run a side-by-side for a week. If the API update and the old feed disagree, fix upstream data, then retire the feed.

Skipping RDT

Problem: operations touching PII require RDT. Without it, you’ll get denials—or worse, compliance exposure.

Fix: integrate Tokens API. Grant least privilege. Rotate tokens. Log access for audits. As Amazon’s docs note, RDT is mandatory for sensitive data access.

Bonus: centralize RDT requests in a small internal service. Everything else calls that service, so you standardize scopes and logging.

No test harness

Problem: manual spot testing doesn’t catch schema or throttling edge cases.

Fix: build a tiny, durable harness that replays your highest-impact workflows with synthetic orders/listings and raises alarms on diffs.

What “good” looks like: assertions on status codes, field-level comparisons, throttle simulation, and a single pass/fail gate you can run in CI or pre-release.

Ignoring The Changelog

Problem: surprise changes.

Fix: assign a DR (Deprecation Ranger). Their job: read the SP-API changelog monthly, update a single source doc, and schedule tests/releases.

Expert quote: “If nobody owns the changelog, you’re choosing outages by default.” — head of platform, 8-figure seller

Quick Pulse Check

  • You’ve mapped all deprecated resources you touch, with removal dates and owners.
  • Listings and Catalog updates run on modern endpoints, not legacy feeds.
  • Notifications payloads are v2+; listing issue alerts flow into your ops channel.
  • RDT is implemented for any PII-sensitive operation; scopes are least-privilege.
  • A sandbox and canary process exist; you watch error rates by operationId.
  • Your team reviews the SP-API changelog monthly and ships on a set cadence.

If you hesitated on any bullet, pick one area and fix it this week. Momentum beats perfection.

FAQs

  1. Q: What happens after a resource’s removal date? A: Calls fail outright. Amazon’s guidance is explicit: deprecated calls work until removal; after that, they return errors. Plan migrations well before the cutoff.

  2. Q: Which feed-based operations are most urgent to replace? A: The Fulfillment Inbound v0-style feeds (e.g., POSTFLATFILELISTINGSDATA, POSTPRODUCTPRICING_DATA) were slated for removal by Dec 20, 2024. Move those to Listings Items and Catalog Items APIs immediately if you haven’t.

  3. Q: Do I need Restricted Data Tokens (RDT)? A: Yes for PII-related access. RDT is required via the Tokens API for sensitive data operations. Implement least-privilege scopes and rotate tokens.

  4. Q: What’s the latest on the Solution Provider Portal migration? A: All SP-API developers must migrate by August 31, 2025. The Portal streamlines app management, auth, and scaling. Delay risks app access issues.

  5. Q: How do Amazon Ads API changes affect me in 2025? A: If you manage impression-generating campaigns via API, migrate by September 30, 2025. Amazon will auto-migrate by December 31, 2025, but you should validate earlier.

  6. Q: How does this compare to Microsoft topics like Patch Tuesday or the NTLM deprecation timeline? A: Use Patch Tuesday’s cadence as a mental model—second Tuesday each month (e.g., December 9, 2025; November 11, 2025). For NTLM, Microsoft signaled deprecation and ongoing reduction in use, but there isn’t a single universal “NTLM deprecation date.” The parallel: both are phased, not overnight.

  7. Q: How should we handle 429 throttling during rollout? A: Respect the usage-plan headers, back off with jitter, and queue non-urgent updates. Start canaries at low concurrency, then scale once error rates stay flat.

  8. Q: We sell across NA and EU. Do we need different tests per marketplace? A: Yes. Attributes, compliance rules, and offer behavior can vary by region. Test at least one SKU per category in each marketplace you sell in.

  9. Q: Do we have to re-authorize our LWA app when moving to the Solution Provider Portal? A: Plan for secret rotation and re-validate redirects/scopes. Test in a lower environment first, then schedule a short maintenance window for prod cutover.

  10. Q: How do we keep PII safe in logs while debugging? A: Mask or drop all sensitive fields, log only hashes or IDs, and store full payloads exclusively in encrypted, access-controlled stores when strictly required.

Ship Your Migration

  • Inventory your endpoints and map to replacements (Listings, Catalog, Notifications v2).
  • Implement RDT via Tokens API where PII is in scope.
  • Build a sandbox harness and run canary releases in production.
  • Set a monthly “changelog review” meeting and assign an owner.
  • Migrate developer access to the Solution Provider Portal early.
  • Document rollback plans for each migration slice.

You don’t need to be first—you just can’t be late. Amazon’s SP-API deprecations are a forcing function: you either modernize your stack or you fight fires. Pick the first path.

Treat this like a product release, not a scramble. Move core listings and catalog flows to modern endpoints, wire up RDT, and hammer your test harness until it squeals. Align to Amazon’s monthly rhythm, keep a human assigned to the changelog, and you’ll turn “breaking changes” into “routine releases.” That’s how you grow through 2026 without waking to a red dashboard.

For real-world examples of migrations and performance lifts, explore our Case Studies.

References