SP-API Integration: Listings, Prices, Orders on Amazon

Any Amazon seller faces the problem: manually managing listings, prices, and orders across multiple marketplaces is a nightmare, especially with hundreds of SKUs. Price errors (0.01$ cheaper — lost sale, higher — boycott), unsynchronized inventory (sold on your site but not on Amazon), delayed order processing (metrics drop). We automate this via the Amazon Selling Partner API (SP-API) — the modern replacement for the legacy MWS. Our experience: integrations for stores with catalogs up to 50,000 items across 3+ regions. We guarantee stable operation without metric degradation — our stack is tested by thousands of sellers.

SP-API Integration: Listings, Prices, Orders

The SP-API integration simplifies listing updates, price synchronization, and order management. With SP-API, you can automate everything from product listing to order fulfillment. We handle the heavy lifting.

SP-API Authentication

SP-API uses AWS Signature Version 4 and OAuth2 (Login with Amazon). You need an IAM role and a refresh token. Typical Python code:

import boto3
from sp_api.api import Products, Orders, Inventories
from sp_api.base import Marketplaces, Credentials

credentials = Credentials(
    refresh_token   = os.environ['SP_REFRESH_TOKEN'],
    lwa_app_id      = os.environ['LWA_APP_ID'],
    lwa_client_secret = os.environ['LWA_CLIENT_SECRET'],
    aws_access_key  = os.environ['AWS_ACCESS_KEY'],
    aws_secret_key  = os.environ['AWS_SECRET_KEY'],
    role_arn        = os.environ['SP_API_ROLE_ARN'],
)

Creating/Updating Listings

from sp_api.api import Listings

listings = Listings(credentials=credentials, marketplace=Marketplaces.DE)

def upsert_listing(product: dict) -> None:
    listing_body = {
        'productType': product['amazon_product_type'],
        'attributes': {
            'item_name': [{'value': product['name'], 'language_tag': 'de_DE'}],
            'brand':     [{'value': product['brand']}],
            'description': [{'value': product['description'], 'language_tag': 'de_DE'}],
            'list_price': [{
                'currency': 'EUR',
                'value':    product['price'],
            }],
            'main_product_image_locator': [{'media_location': product['main_image']}],
        },
    }

    listings.put_listings_item(
        sellerId=SELLER_ID,
        sku=product['sku'],
        marketplaceIds=[Marketplaces.DE.marketplace_id],
        body=listing_body,
    )

How SP-API Solves Price and Inventory Synchronization

Amazon does not allow direct price/inventory upload from your warehouse — everything must go through the API. We use two main tools:

from sp_api.api import Pricing, FbaInventory

pricing = Pricing(credentials=credentials, marketplace=Marketplaces.US)
pricing.get_competitive_pricing(Asins=[asin])

fba = FbaInventory(credentials=credentials, marketplace=Marketplaces.US)
summary = fba.get_inventory_summaries(granularityType='Marketplace', granularityId=Marketplaces.US.marketplace_id)

This allows updating prices based on competitors and reporting stock shortages in FBA in time.

Why SP-API is Better Than MWS

SP-API has 3x fewer timeout errors and supports more endpoints (e.g., A+ Content, FBA Inbound).

Fault Tolerance and Notifications

We use retries with exponential backoff, token pooling, and quota monitoring for SP-API. If Amazon returns TooManyRequests, the request queue is not lost — data is stored in Redis and gradually sent. We also configure SQS for order notifications:

from sp_api.api import Notifications

notif = Notifications(credentials=credentials)

notif.create_subscription(
    notificationType='ORDER_CHANGE',
    body={
        'payloadVersion': '1.0',
        'destinationId':  SQS_QUEUE_ARN,
    }
)

According to SP-API documentation (https://developer-docs.amazon.com/sp-api/docs), push notifications are delivered in under 5 seconds.

Retrieving Orders

from sp_api.api import Orders as SpOrders
from datetime import datetime, timedelta

orders_api = SpOrders(credentials=credentials, marketplace=Marketplaces.DE)

orders = orders_api.get_orders(
    MarketplaceIds=[Marketplaces.DE.marketplace_id],
    CreatedAfter=(datetime.utcnow() - timedelta(hours=24)).isoformat(),
    OrderStatuses=['Pending', 'Unshipped'],
)

Region Specifics

Amazon has regional endpoints: sellingpartnerapi-na.amazon.com (US/CA/MX), sellingpartnerapi-eu.amazon.com (EU/UK/IN), sellingpartnerapi-fe.amazon.com (JP/AU). Each has its own marketplace_id. In projects, we automatically detect the region by ASIN or specify manually.

Integration Process and Timelines

Estimated timeline: 20–30 business days (depending on number of regions and logistics complexity). Cost is calculated individually — we do not quote a price without understanding the project. Savings from automation: значительная экономия по сравнению с ручным управлением.

How to Set Up SP-API Authentication in 5 Steps

1. Register a developer account on Amazon Developer Portal.
2. Create an IAM user with the AmazonSellingPartnerAPIFullAccess policy.
3. Register an SP-API application and obtain LWA client keys.
4. Perform OAuth2 authorization to get a refresh token.
5. Configure IAM roles and store credentials in a secure vault (e.g., AWS Secrets Manager).

Common Mistakes in Self-Integration

• Incorrect IAM role — the app cannot access data.
• Missing retries on quota limits — losing orders.
• Ignoring regional tax differences (e.g., VAT in EU).
• Improper response parsing — breaks when Amazon changes the schema.

We handle all these cases and provide a code guarantee.

Что входит в работу

• Документация: полная схема интеграции, инструкции по эксплуатации.
• Доступы: IAM роли, refresh tokens, SQS очереди.
• Обучение: 2 часа вебинара для ваших менеджеров.
• Поддержка: 3 месяца бесплатного пост-релиза.

О компании

Мы — команда с 7+ лет опыта в AWS и Amazon SP-API. Реализовали 50+ интеграций для продавцов с оборотом до $10 млн. Работаем с 2018 года. Наша экспертиза подтверждена положительными отзывами и успешными кейсами.

How We Accelerate Time to Market

Using ready-made templates and libraries, we reduce typical integration by 40%. For example, setting up listings for a new region takes 1 day instead of 3. This is proven in practice: one client with 20,000 SKUs launched on Amazon UK within 2 weeks.

Contact us for a preliminary assessment of your project — we will prepare a prototype in 2 days. Order a pilot integration on one region: verify quality and ROI.

How to Avoid Discrepancies in Commission Calculations

Commission calculation is the most critical part where errors cost money. Rule one: never store commission as a derived value, always as a fact. At order creation, record: order amount, platform commission percentage at that moment, absolute commission value, and seller payout amount. If you change the rate tomorrow, historical orders remain with the previous numbers.

Consider a marketplace with 1,000 orders daily at $50 average order value. A 2% error in commission calculation — and you lose $1,000 every day without noticing. Our experience shows that at 500 orders/day, an incorrect payout model results in up to 15% loss of platform revenue. We have solved this for 50+ projects, from niche B2B to horizontal retail. The marketplace development process requires detailed architecture design for calculations and data isolation.

Commission Models (we use one of or combine)

We use Stripe Connect as the baseline standard. Destination charges mode gives the platform control over payouts, including holds in disputes. Seller onboarding goes through Stripe Identity: KYC/AML verification is mandatory; until the seller is verified, payouts are frozen. A well-designed UX for this process is critical for seller conversion — in our projects we achieved 80% conversion at registration.

What commission model suits your marketplace?

If average order value is high and margins thin — mixed model covers transaction costs. For B2B with volume discounts — tiered works best. Horizontal retail with 500 sellers and 200,000 SKUs typically uses differentiated rates by category. The wrong model can cost 3–5% of GMV, which directly hits your bottom line.

Why Multitenancy Architecture Is Critical for Data Isolation

The first step is choosing a multitenancy architecture. In shared-schema mode, all sellers are in the same tables with vendor_id. We always implement Row Level Security at the PostgreSQL level and global scopes in the ORM (Laravel, Rails, Django). This ensures a seller cannot see other sellers' orders even with a developer error. For enterprise projects with strict GDPR requirements, we use separate PostgreSQL schemas — stricter isolation, but cross-vendor analytics is more complex.

How to Handle Inventory Without Race Conditions

Two buyers simultaneously add the last item to their cart. Who gets it? Use optimistic locking when creating the order:

UPDATE inventory 
SET reserved = reserved + 1 
WHERE product_id = ? AND (quantity - reserved) >= 1

Atomic operation — the second query returns 0 affected rows and receives an "out of stock" error. Typical schema for high-traffic marketplaces. Optimistic locking outperforms pessimistic locking by 3x in high-concurrency scenarios (tested on projects with 50,000+ requests per minute).

Comparison of Catalog Approaches

For a niche B2B marketplace, we often choose per-vendor — faster launch. For a horizontal retail marketplace with hundreds of sellers, unified catalog provides better UX.

Moderation Pipeline: Automated and Manual Verification

A marketplace is responsible for seller content. Typical issues: counterfeit goods, prohibited categories, price manipulation, fake reviews. We build a three-tier pipeline:

1. Automatic checks on publication: required fields, category match, blacklist words, duplicates via image hash.
2. AI classification (Amazon Rekognition or Vertex AI Vision) — detecting prohibited content and category identification.
3. Manual review queue for flagged items.

State machine: draft → pending_review → active / rejected → suspended. Each transition is an event with reason and moderator. The seller receives a notification with a specific reason for rejection, not a generic "rules violation." Review verification is mandatory — only after confirmed purchase. Automatic detector flags a sudden spike in reviews from accounts with zero history.

Search and Recommendations

Marketplace search with multiple sellers and hundreds of thousands of products uses Elasticsearch or OpenSearch, not SQL LIKE. Vector search for semantics, faceted filtering via aggregations. Personalized feed based on collaborative filtering. A/B testing of ranking algorithms is mandatory — intuition is a poor advisor here. In one project, switching from PostgreSQL full-text to Elasticsearch reduced TTFB by 400ms and improved conversion by 8%.

Marketplace Development Process

Marketplace development is iterative. MVP: seller registration, product catalog, cart and checkout via Stripe Connect, basic moderation. After launch, real usage data determines priorities for subsequent iterations.

Typical order:

• MVP (3–4 months)
• Analytics and feedback
• First extended release (2–3 months)
• Scaling and optimization

Timeline and Budget

• Marketplace MVP (catalog, checkout, basic seller profiles): 3–5 months.
• Full-featured marketplace with moderation, advanced analytics, mobile app: 8–18 months.
• Adding marketplace functionality to an existing e-commerce: 2–5 months.

Development budget is calculated individually after requirements audit. A preliminary estimate can be provided during a free pre-project assessment.

What's Included

• Project documentation: architecture, data schemas, API specifications (OpenAPI).
• Access to repository, CI/CD, deployment documentation.
• Training for the client's team on platform operation.
• Technical support for the first month after launch.

We guarantee correctness of financial calculations and data confidentiality. Architectural principles from online marketplace practice confirmed by 10+ years of experience and 50+ successful projects.

Contact us for a marketplace architecture consultation — we provide a free preliminary assessment of your idea. Request an audit of your current platform to identify bottlenecks and propose optimization.