You built on a free pipe for years. Now Amazon wants rent.
January 2026 SP-API flipped the switch. Third-party devs move from free to a subscription plus usage fees. Sellers using SP-API directly for their own business stay free. If you build tools for sellers or vendors, your costs just changed.
Here are the headline numbers. A $1,400 annual subscription starts January 31, 2026. Monthly GET-call billing starts April 30, 2026. Translation: your architecture, pricing, and margins now depend on call efficiency. Every wasted call burns real cash, fast.
If you’ve been waiting for a firm release date, this is it. If you wanted price clarity, you’ve got enough to plan now. The Basic tier includes 2.5 million GET calls per month with no extra monthly fee. Tiers scale up to Enterprise, which can reach $10k per month. Overage costs $0.40 per 1,000 GET calls. Efficient apps win. Sloppy ones pay, badly.
Bottom line: set up billing in the Solution Provider Portal. Measure your GET footprint. Make your app cheaper to run before the meter starts. Teams that optimize early will keep prices steady and take share from slower rivals.
TLDR
- New fees target third-party developers on SP-API; sellers’ direct use stays free.
- $1,400 annual subscription bills Jan 31, 2026; set up payment now.
- Monthly GET-call billing starts Apr 30, 2026; tiers from Basic to Enterprise.
- Basic includes 2.5M GET calls; overage is $0.40 per 1,000.
- Remove Professional plan requirement; billing moves to Solution Provider Portal.
- Optimize with caching, batching, and monitoring to defend margins.
What Changed From Free Pipes
Two part fee to budget
The January 2026 update makes a paid model just for third-party developers:
- Annual subscription: $1,400 USD, effective January 31, 2026. This unlocks the Solution Provider Portal, production rights, and support.
- Monthly usage fees for GET calls: effective April 30, 2026, with tiered bundles (Basic, Pro, Plus, Enterprise) and overage at $0.40 per 1,000 GET calls.
This is the first real cost shift since the MWS era, launched in 2009, that SP-API replaced. Amazon’s stated reason: align fees with ongoing investment in reliability, features, and developer support.
Reference: See the latest SP-API release notes and deprecation schedule for the authoritative details and dates.
What this means in practice: your app’s economics now tie to your engineering choices. Each GET call is latency and money. If you architect like it’s still free, you’ll torch your tier and margin. If you build for efficiency, you can ride Basic longer and scale predictably when needed.
Who pays and who doesnt
- You pay if: you’re a third-party developer building apps for sellers, vendors, or partners.
- You don’t pay if: you’re a seller or vendor using SP-API directly for your own business.
And one simplifier: you no longer need an Amazon Professional selling plan to build.
Common scenarios so you can self-sort:
- Agencies and integrators offering dashboards, syncs, or automation to clients: you pay.
- Market intelligence, repricing, catalog, ads, or ops SaaS platforms: you pay.
- A single brand pulling its own catalog and orders into an internal ERP: no developer fees.
- Aggregators with an internal tool for their owned brands: usually direct use; confirm how your permissions and accounts are structured.
Dates you cannot miss
- November 3, 2025: billing setup opened in the Solution Provider Portal.
- January 31, 2026: annual subscription billing starts; payment and tax info due.
- February 9, 2026: non-compliant apps removed from the Appstore; new authorizations blocked.
- February 16, 2026: SP-API access suspended for non-compliant apps; sellers notified.
- April 30, 2026: monthly GET-call fees begin.
First-hand example: A small dev launching a niche inventory sync app can stay on Basic if they keep GET calls under 2.5M per month. That buffer lets you launch lean—if you design for efficiency from day one.
Operational checklist for next standup
- Assign an owner for billing and tax setup, no shared inbox surprises.
- Map your current GET usage, trailing 30/90 days, per endpoint.
- Verify you can see usage dashboards in the Solution Provider Portal.
- Create calendar reminders one week before each milestone.
- Draft customer comms now, don’t scramble later.
How GET Billing Works
Tier math in plain English
Amazon’s usage billing only counts GET calls. POST, PUT, DELETE are not billable under this model. The tiers:
- Basic: 2.5M GET calls per month included; $0 monthly fee, covered by your annual subscription.
- Pro / Plus / Enterprise: higher included bundles up to 250M+ calls. Pricing scales, with Enterprise up to $10,000 per month.
Exact Pro and Plus pricing appears in your Solution Provider Portal once you subscribe. Choose your tier, then monitor against the cap closely.
What doesn’t change: your rate limits and throttles still apply per endpoint as documented. The fee model doesn’t remove throttling. Poorly timed bursts still trigger slowdowns and retries. Design to stay under throttle limits and within your fee tier.
The overage economics
Overage is $0.40 per 1,000 extra GET calls. That’s $400 per additional million calls. Quick gut-check:
- If you’re consistently over Basic by 10M calls, that’s about $4,000 in overage. A higher tier may be cheaper if the monthly fee pencils out.
- If your spikes are occasional, overage might be fine. The finance call is predictable run rate vs paying for peak.
Break-even habit: compare your trailing-90-day average overage cost to the next tier’s monthly fee. If overage beats the next tier for two straight months, you’re probably under-tiered.
Realistic example to map costs
Example: You run an analytics app averaging 18M GET calls per month.
- Option A: Stay Basic and pay overage on 15.5M calls, which is about 15,500 blocks x $0.40 = $6,200 per month.
- Option B: Move to a higher tier that includes up to 25M. If the Pro-tier fee is less than $6,200, you win on cost and predictability.
More quick math to calibrate your radar:
- 3M calls per month on Basic: 0.5M overage ≈ 500 blocks x $0.40 = $200 per month. Many early-stage apps can live here comfortably.
- 12M calls per month on Basic: 9.5M overage ≈ 9,500 blocks x $0.40 = $3,800 per month. You’re probably ready for a mid-tier.
- 60M calls per month: if a tier covers 50M, the extra 10M overage is about $4,000; compare that to the next tier carefully.
Use the portal’s dashboards to track trailing 30/90-day usage and pick a tier that matches your real world, not your wishful estimates. And remember, GET calls you don’t make are the cheapest calls on earth.
Where to verify your numbers
- Solution Provider Portal: usage dashboards and tier settings.
- Per-tenant logging: build your own counters by endpoint and customer to attribute cost to features.
- Alerts: page the team long before the cap. 60% is check systems, 80% is act now, and 95% is ship a hotfix or flip efficiency mode.
Ship Efficiently Cut GET Noise
Caching and deduping best friends
High-frequency polling is where margins go to die. Cache what you can within SLA windows. For stable catalog data, cache hours; for prices, minutes. For near-real-time events, consider webhooks or incremental pulls where supported. De-duplicate by request intent and avoid re-fetching unchanged payloads.
Practical example: A listings dashboard querying 20k SKUs every five minutes can slash calls by 40%. Cache unchanged results for 30 minutes and switch to incremental refresh for only changed-since timestamps.
Implementation notes your engineers will thank you for:
- Normalize requests so identical inputs hit the cache, including consistent casing and sorted query params.
- Use short TTLs for volatile data and longer TTLs for slow changers.
- Add request coalescing: if five threads ask for the same item, perform one GET and fan out the result.
- Cache negative lookups, like missing SKUs, briefly to avoid hammering endpoints.
Prefer async reports and notifications
SP-API supports asynchronous Reports and Notifications. When possible, swap poll 10,000 times for request a report, wait, fetch once. That’s fewer GET calls and happier throttles.
- Reports: batch data pulls on a schedule instead of constant small reads.
- Notifications: react to events rather than scanning for changes.
If a feature is event-driven, like orders, shipments, or listing changes, start with Notifications. Use GET only for detail expansion on new or changed records.
Batch backoff and schedule
- Batch supported endpoints to reduce per-item GETs.
- Apply exponential backoff and jitter to avoid retry storms.
- Schedule heavy jobs off-peak to flatten usage spikes and keep your app responsive during the day.
Amazon publishes best practices and endpoint-specific guidance on what’s billable vs not. Align your code to their guidance, not your assumptions.
Small but mighty wins
- Paginate smartly, don’t pull empty pages, stop when results are exhausted.
- Respect end-to-end timeouts to avoid duplicate retries.
- Treat 4xx and 5xx errors as expensive. Instrument and fix the root cause quickly.
Monitor alert and iterate
Instrument your GET rates by endpoint, customer, and feature. Set alerts at 60%, 80%, and 95% of your monthly cap. When a new feature ships, watch its GET footprint for two weeks and tune. The first month under the new billing regime will teach you more than any spreadsheet.
Need deeper, endpoint-level visibility and faster root-cause analysis? Explore Requery.
First-hand example: A repricer cut GET calls by 52% after merging duplicate catalog fetches. They switched to on-change refresh via asynchronous reports where supported. Same outcomes for sellers, half the provider’s cost.
Efficiency checklist for backlog
- Replace polling with Notifications or Reports where possible.
- Add TTL-based caches and request coalescing.
- Consolidate hot endpoints behind a service layer with per-tenant quotas.
- Kill redundant refreshes triggered by UI focus or blur.
- Add feature flags for efficiency mode during spikes, longer intervals and fewer GETs.
- Build a dashboard: top endpoints by GET volume, top customers by GET spend, and error rates tied to retries.
Rebuild pricing and margins
Who absorbs what and how
If you run a SaaS for Amazon sellers, assume your COGS now includes GET spend. Options:
- Absorb the fee short term while you optimize.
- Add a usage component tied to API intensity, like SKUs tracked, stores connected, and refresh frequency.
- Offer Efficiency Plans that throttle to stay inside a tier cap.
Keep it transparent: "Amazon introduced SP-API fees for third-party apps. We’ve optimized calls and kept you in the lowest viable tier. Here’s how we’re minimizing impact." Sellers respect clarity.
Positioning tips so customers don’t panic:
- Share your optimization wins, like we cut GET chatter 41% last month.
- Explain in plain English how plans map to cost drivers.
- Offer an opt-in efficiency mode to keep their bill, and yours, predictable.
Packaging tiers that map
- Starter: 1 store, 10k SKUs, 15-minute refresh. Targets Basic tier.
- Growth: 3 stores, 50k SKUs, 5-minute refresh. Targets mid-tier.
- Scale: 10+ stores, 200k SKUs, near-real-time refresh. Targets Plus or Enterprise.
By packaging around usage drivers, you align pricing directly to cost. That reduces bill shock for you and for the customer.
A simple unit economics sketch to guide pricing:
- Pooled included GET calls per month equals your tier allowance.
- Estimated customer GET footprint equals stores x avg SKUs x refreshes per day x days, adjusted by cache hit rate.
- Overage cost ≈ max(0, (total GET – included GET) / 1,000) x $0.40.
- Margin buffer equals price minus infra, support, and expected GET overage share.
Proving value under pressure
A price increase lands better when paired with speed, reliability, and outcomes. Use the switch to ship upgrades sellers can feel. We cut latency 35%, expanded historical analytics, and reduced downtime. Here’s the roadmap.
Example: A catalog tool introduced a smart sync mode that prioritizes fast-moving SKUs. It shifts slow movers to hourly. Sellers kept insights; the provider cut GET volume 38%.
Messaging that works:
- "We re-architected for efficiency so you can stay in the lowest tier possible."
- "Your plan includes X included SKUs and Y refresh cadence; you control the dials."
- "If you scale, we scale with you—no surprise overages without alerts."
Compliance dont miss dates
The setup sequence
- Add billing and tax details in the Solution Provider Portal, card on file required.
- Confirm subscription activation and review tier options.
- Turn on usage monitoring and set monthly alerts.
Amazon’s timeline is strict. Billing setup opened November 3, 2025. Annual subscriptions begin billing January 31, 2026. Miss that, and here’s what happens.
Enforcement milestones
- February 9, 2026: apps without valid payment or tax info are removed from the Selling Partner Appstore and blocked from new authorizations.
- February 16, 2026: SP-API access suspended for non-compliant apps; authorized sellers are notified your app is unavailable.
- April 30, 2026: monthly GET-call billing kicks in.
Team ownership to avoid pain
- Finance: owns card, tax profile, and receipts.
- DevOps: owns usage monitoring and alerting.
- Product: owns feature toggles for efficiency modes.
- Support or Success: owns customer comms and status updates.
Communication and contingency
Email customers before each milestone. Share your compliance status, expected impact, and your optimization plan. If you’re de-listed or suspended, provide an offline contingency, like export keys and spreadsheet backups, so customers can operate meanwhile. That trust buys you time.
First-hand example: A reporting app ran a billing readiness webinar. They sent a checklist to customers and offered a one-click efficiency mode. Churn risk dropped, NPS went up, and support tickets fell during the transition.
- How to export critical data.
- How to temporarily extend refresh intervals.
- Where to see real-time status updates.
- How to contact support if an authorization breaks.
Speed Bump Recap
- Third-party developers now pay: $1,400 annual plus GET usage from Apr 30, 2026.
- Sellers using SP-API directly for their own operations stay free.
- Basic includes 2.5M GET calls per month; overage costs $0.40 per 1,000.
- Miss Feb 9 and 16, 2026 compliance milestones and you risk removal or suspension.
- Optimize with caching, batching, and better scheduling to defend margins.
- Map app pricing to usage drivers, like stores, SKUs, and refresh rates, for alignment.
FAQ Dates Pricing What Next
- Q: What’s the SP-API January 2026 release date that matters?
A: The key billing dates are January 31, 2026 for the $1,400 annual subscription and April 30, 2026 for monthly GET-call fees. Billing setup opened November 3, 2025.
- Q: Are Amazon sellers charged for direct SP-API use?
A: No. Sellers and vendors using SP-API for their own business remain free. The fees apply to third-party developers building apps for others.
- Q: Do POST, PUT, or DELETE calls count toward usage fees?
A: No. The usage billing is based on GET call volume. Amazon provides endpoint-level guidance to help you understand what’s billable.
- Q: Do retries count toward my GET total?
A: Assume yes. If your code issues a GET—even as a retry—that’s a GET. Design with backoff and jitter to reduce repeat requests.
- Q: Do I still need a Professional selling plan in Seller Central?
A: No. Amazon removed the Professional plan requirement for third-party developers. Your billing and app management run through the Solution Provider Portal.
- Q: What happens if I don’t add billing and tax info?
A: Your app can be removed from the Selling Partner Appstore and blocked from new authorizations by February 9, 2026. Your SP-API access can be suspended by February 16, 2026. Sellers are notified.
- Q: Where do I find the exact Pro, Plus, and Enterprise prices?
A: Pricing details appear in the Solution Provider Portal after you subscribe. Enterprise can reach up to $10,000 per month depending on bundle size.
- Q: What’s the fastest way to lower my GET calls without gutting features?
A: Swap frequent polling for Reports or Notifications. Add short TTL caches, dedupe identical requests, and add an efficiency mode toggle that lengthens refresh intervals during spikes.
- Q: How should agencies with many small clients plan tiers?
A: Treat your included GET calls as a pooled allowance. Attribute usage per client internally so you can price fairly, but pick tiers based on aggregate run rate.
- Q: Could Amazon change what’s billable in the future?
A: Policies can evolve. Monitor the SP-API release notes and announcements so you’re not caught flat-footed.
90 Day SP API Playbook
- Week 1: Add payment and tax info in the Solution Provider Portal; confirm subscription.
- Week 2–3: Instrument GET usage by endpoint, customer, and feature; set 60, 80, and 95% cap alerts.
- Week 4–6: Ship caching, dedupe, and batching; eliminate redundant polling and retry storms.
- Week 7–8: Forecast the next 90 days of GET volume; pick a tier; model overage vs monthly fee.
- Week 9: Update pricing and packaging; add efficiency mode settings for customers.
- Week 10–12: Communicate timeline and changes; run load tests; re-check Dashboards weekly.
Wrap-up: Lock your tier, turn on monthly reviews, and keep optimizing.
Here’s the game: Amazon just put a meter on your GET lane. It’s not a tax—it’s a forcing function. If you harden architecture, batch wisely, and price against real workloads, you’ll come out stronger. The Basic tier’s 2.5M cushion keeps entry accessible. The upper tiers let serious platforms scale. The winners won’t be the loudest or the biggest, they’ll be the most efficient. Start with your top three noisy endpoints, turn waste into wins, and make April 30 a non-event for your customers.
Looking for real-world examples of efficiency wins and revenue impact? Browse our Case Studies.
References