Amazon SP-API Fees in 2026: What You'll Pay and How to Minimise Costs

Amazon’s Selling Partner API was free to use from its launch in 2020 through the end of 2025. That changed in January 2026. Amazon introduced a two-part pricing model: an annual subscription fee plus usage-based billing based on API call volume.

For sellers using third-party tools that rely on the SP-API — inventory management platforms, repricing tools, analytics dashboards, fulfilment software — this means higher costs passed through by your software providers. For developers building SP-API integrations, this directly changes the cost calculation for your projects.

This guide breaks down exactly what you’ll pay, how to estimate your costs, and the most effective strategies to reduce your API usage without losing data fidelity.

The 2026 SP-API Pricing Structure

Amazon’s pricing model has two components:

Component 1: Annual Subscription Fee

$1,400 per selling partner application per year (charged to the developer who registered the application, not to individual sellers using it).

This applies to each SP-API developer application registration. If you’re a seller using third-party software, your software provider pays this fee — and may pass it through to you in their pricing.

If you’re a developer who built a custom private application for a single seller account, you pay $1,400/year for that application.

Who is exempt? Amazon has indicated that very low-volume applications (under a threshold of total API calls) may qualify for a reduced or waived subscription — but this threshold has not been publicly documented clearly. Contact the SP-API developer support team for confirmation on your specific case.

Component 2: Usage-Based Billing

On top of the subscription, Amazon charges per API request based on call volume tiers. The billing is applied per API operation group, not per individual endpoint.

Monthly Call Volume	Rate per 1,000 requests
First 10,000 calls	Free (included)
10,001 – 1,000,000	$0.09 per 1,000
1,000,001 – 10,000,000	$0.07 per 1,000
10,000,001+	$0.05 per 1,000

High-volume API operations (Orders API, Catalog Items API, Reports API) each have their own billing counters.

Official reference: Amazon SP-API pricing page

Worked Example: Mid-Size Seller

A seller with 500 orders/month using a third-party tool that:

Fetches all orders daily: 500 orders × 30 days = ~15,000 order API calls/month
Refreshes inventory every hour: 1,000 SKUs × 24 × 30 = 720,000 inventory calls/month
Fetches listings weekly: 1,000 listings × 4 = 4,000 catalog calls/month

Total calls: ~739,000/month

Estimated cost:

Subscription: $1,400/year = ~$117/month
Usage: (739,000 - 10,000) = 729,000 billable calls × $0.09/1,000 = $65.61/month
Monthly total: ~$183/month

Compare this to $0/month in 2025. For a typical mid-size seller, costs have moved from zero to $150–250/month.

Which APIs Are Most Expensive?

Not all APIs contribute equally to your bill. These are the highest-volume operations that most sellers and developers rely on:

Orders API (getOrders)

Polling the Orders API frequently is the most common source of high call volume. Tools that check for new orders every 5 minutes make 288 calls per day just to monitor order status.

Optimisation: Switch to order notifications via Amazon EventBridge or Notifications API instead of polling. A notification arrives when an order is created — no polling needed.

Catalog Items API (listCatalogItems / getItem)

Looking up product details, ASIN data, or catalogue information at SKU level can generate millions of calls for large catalogues.

Optimisation: Cache catalogue data locally and refresh only when attributes change (via the Listings Items API change notification).

Inventory (FbaInventory / Inventory Summaries)

Refreshing inventory levels frequently for accurate stock display or repricing logic.

Optimisation: Use the Reports API to download bulk inventory snapshots rather than individual item lookups.

Feeds/Reports API

Less expensive per call but report generation counts toward billing when using the createReport → getReportDocument pattern.

7 Strategies to Reduce Your SP-API Costs

Strategy 1: Use the Reports API for Bulk Operations

The SP-API has two approaches for getting the same data:

Direct API calls: One request per order/SKU/listing — high call volume
Reports API: Request one report → download a file with thousands of records — minimal calls

For any operation where you need data across your whole catalogue or all orders, the Reports API is dramatically more efficient.

Example: Getting inventory for 10,000 SKUs

Individual calls: 10,000+ API calls
Reports API: 3 calls (createReport, getReportDocument status check, download URL) + 1 file download

High-value reports for cost reduction:

GET_MERCHANT_LISTINGS_ALL_DATA — all active listings with full attributes
GET_FBA_MYI_UNSUPPRESSED_INVENTORY_DATA — full FBA inventory snapshot
GET_FLAT_FILE_ORDERS_DATA_BY_ORDER_DATE_GENERAL — all orders in a date range

import requests
from time import sleep

def create_and_download_report(report_type, start_date, end_date, headers, marketplace_id):
    # Step 1: Request the report
    response = requests.post(
        'https://sellingpartnerapi-eu.amazon.com/reports/2021-06-30/reports',
        headers=headers,
        json={
            "reportType": report_type,
            "dataStartTime": start_date,
            "dataEndTime": end_date,
            "marketplaceIds": [marketplace_id]
        }
    )
    report_id = response.json()['reportId']

    # Step 2: Poll for completion (exponential backoff)
    wait = 30
    for _ in range(10):
        sleep(wait)
        status_resp = requests.get(
            f'https://sellingpartnerapi-eu.amazon.com/reports/2021-06-30/reports/{report_id}',
            headers=headers
        )
        status = status_resp.json()
        if status['processingStatus'] == 'DONE':
            document_id = status['reportDocumentId']
            break
        wait = min(wait * 1.5, 300)

    # Step 3: Get the document URL and download
    doc_resp = requests.get(
        f'https://sellingpartnerapi-eu.amazon.com/reports/2021-06-30/documents/{document_id}',
        headers=headers
    )
    download_url = doc_resp.json()['url']
    data = requests.get(download_url)
    return data.content

This replaces thousands of individual calls with a 3-call sequence.

The SP-API Notifications API lets you subscribe to push events — Amazon sends you a message when something changes rather than you checking repeatedly.

Available notifications:

ORDER_CHANGE — fires when an order is created, updated, or cancelled
LISTINGS_ITEM_STATUS_CHANGE — fires when a listing changes status
FBA_OUTBOUND_SHIPMENT_STATUS — fires when FBA shipment status updates
PRICING_HEALTH — fires when Amazon flags pricing issues

Set up notifications with Amazon EventBridge:

# Subscribe to ORDER_CHANGE notifications
response = requests.post(
    'https://sellingpartnerapi-eu.amazon.com/notifications/v1/subscriptions/ORDER_CHANGE',
    headers=headers,
    json={
        "payloadVersion": "1.0",
        "destinationId": "your-eventbridge-destination-id"
    }
)

This alone can eliminate 80–90% of your Orders API polling calls.

Strategy 3: Implement Intelligent Caching

Most SP-API data doesn’t change minute-to-minute. A product’s ASIN, title, and category don’t change hourly. Cache this data in your database and refresh it on a schedule rather than fetching it on every request.

Recommended cache durations:

Data type	Recommended TTL
Product catalogue / ASIN details	24 hours
Listing attributes and images	12 hours
FBA fee estimates	24 hours
Pricing data	5–15 minutes (changes frequently)
Order status	Real-time (use notifications)
Inventory levels	1 hour (or use change notifications)

A Redis or database-backed cache can reduce your call volume by 60–80% with no loss in data quality.

Strategy 4: Reduce Polling Frequency

If you’re polling any SP-API endpoint more frequently than your business actually requires real-time data, reduce it:

Inventory reports: Do you need hourly? Or is 4×/day sufficient for your repricing logic?
Order checks: Notifications replace polling entirely
Listing sync: Weekly or on-change rather than daily

Audit each API call your integration makes and ask: “What business decision does this data inform, and how fresh does it need to be?”

Strategy 5: Use Batch Operations

Several SP-API endpoints support batching — fetching multiple items in a single request:

# Inefficient: One request per ASIN (100 calls for 100 ASINs)
for asin in asin_list:
    response = requests.get(f'/catalog/2022-04-01/items/{asin}', headers=headers)

# Efficient: Batch request (fewer calls)
response = requests.get(
    '/catalog/2022-04-01/items',
    headers=headers,
    params={
        'identifiers': ','.join(asin_list[:20]),  # up to 20 per request
        'identifiersType': 'ASIN',
        'marketplaceIds': marketplace_id,
        'includedData': 'attributes,images,productTypes,summaries'
    }
)

Where batching is available, it reduces call volume proportionally to batch size.

Strategy 6: Consolidate Applications

If your business runs multiple SP-API developer applications (e.g., separate apps for inventory, orders, and analytics), each pays the $1,400 annual subscription. Consolidating to a single application with multiple scopes eliminates redundant subscription fees.

Review your registered applications in Seller Central → Apps & Services → Develop Apps. Any low-usage applications that can be merged into a primary application should be consolidated before your next annual billing date.

Strategy 7: Audit Third-Party Tools

If you use multiple third-party tools (inventory manager, repricer, analytics dashboard, shipping software), each may be calling the SP-API independently and redundantly. Ask each vendor:

How many API calls does their integration make per day?
Do they use caching and notifications?
Have they updated their pricing to reflect SP-API fees?

Tools that were built when SP-API was free may not have been optimised for call volume. Vendors who haven’t updated their architecture since the fee introduction may be passing significant costs to you unnecessarily.

How SP-API Fees Affect Third-Party Sellers

For sellers who use software tools rather than building their own SP-API integrations, the fee impact comes through your software vendors:

Inventory management tools (Linnworks, Brightpearl, Skubana): Expect price increases of $20–80/month
Repricing tools (Repricer.com, BQool, Seller Snap): High API usage for real-time price monitoring — expect $30–100/month increases
Analytics platforms (SellerBoard, Helium 10): Expect $10–40/month increases

Some vendors absorb these costs; others itemise them as a line item. Review your software subscription invoices for SP-API fee pass-throughs.

Is the SP-API Still Worth It?

For most sellers, yes. The SP-API provides access to data and capabilities that Amazon’s Seller Central UI simply can’t provide at scale:

Automated order processing at volume
Real-time inventory synchronisation across channels
Bulk listing management
Detailed financial reconciliation

The new fees represent a meaningful but manageable cost for the operational efficiency the API provides. The key is building or choosing software that has been optimised for the fee environment rather than tools built for the free era.

We build SP-API integrations with billing efficiency built in from the start — notifications instead of polling, bulk operations, and intelligent caching. Book a free consultation to discuss your SP-API integration requirements.