Reference · built on requestConnectorCommerce & orders

Amazon SP-API

Orders, FBA inventory, reports, and event notifications from Amazon seller accounts through SP-API, one marketplace at a time.

Request accessPricing ↗

About

SP-API is Amazon's REST interface for sellers and vendors. The Orders API returns orders created or updated in a time window per marketplace; the FBA Inventory API reports stock in Amazon's fulfillment network; the Reports API and Feeds API move bulk data; the Notifications API pushes events such as FBA_INVENTORY_AVAILABILITY_CHANGES to an Amazon SQS queue or Amazon EventBridge. Buyer names and addresses sit behind a Restricted Data Token.

An operator on Fibric reads unshipped orders, watches FBA availability changes, and proposes a shipment confirmation with tracking, or a shipment status update, for your approval. Every proposal leaves a receipt: what changed, why, and how to undo it.

This is a reference listing. It documents what Fibric would read from Amazon SP-API and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Orders by marketplace and time window through getOrders, with getOrderItems for the lines
  • Order status values Pending, Unshipped, PartiallyShipped, Shipped, Canceled, Unfulfillable, InvoiceUnconfirmed, and PendingAvailability
  • Buyer and shipping address details through getOrderBuyerInfo and getOrderAddress, under a Restricted Data Token
  • Stock in Amazon's fulfillment network through the FBA Inventory API
  • Notifications such as FBA_INVENTORY_AVAILABILITY_CHANGES, FBA_OUTBOUND_SHIPMENT_STATUS, and FEED_PROCESSING_FINISHED delivered to SQS or EventBridge
  • Report and feed processing results through the Reports API and Feeds API

Proposed actions

  • Target capability: propose confirmShipment with packageDetails, trackingNumber, carrierCode, and shipDate
  • Target capability: propose updateShipmentStatus to ReadyForPickup, PickedUp, or RefusedPickup
  • Target capability: propose a feed submission through the Feeds API for bulk order or inventory updates

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Confirm shipment the minute the label prints

    Take the carrier's tracking number from ShipStation and propose confirmShipment for the Unshipped order, so Amazon's status and the buyer's page agree.

    With Tracking Sync, Missed Delivery

  • Know FBA is running dry before the listing does

    Subscribe to FBA_INVENTORY_AVAILABILITY_CHANGES, forecast when fulfillable stock reaches zero, and propose an inbound plan.

    With Stockout Forecast, Channel Allocation

  • Reconcile marketplace orders with the ledger

    Read orders by marketplace and window, match them to NetSuite sales orders, and flag the ones missing on either side.

    With Payout Reconciliation, Channel Mix

  • Route a late pickup before it becomes a defect

    Watch orders past their expected ship date and propose updateShipmentStatus or a shipment confirmation with today's date.

    With Promise Date, Stalled Shipment

Requirements

  • A registered developer application with the roles it needs; sellers reauthorize annually or when roles change
  • The Direct to Consumer Shipping (Restricted) role and a Restricted Data Token for buyer info and shipping addresses
  • An Amazon SQS queue or Amazon EventBridge bus you own as the notification destination
  • A marketplace ID for each region the seller trades in, since orders and inventory are fetched per marketplace
Authentication
OAuth 2.0 through Login with Amazon (LWA): a public app is authorized by the seller through the website or Appstore workflow, a private app self-authorizes in Seller Central, and PII calls add a Restricted Data Token.

Limits

  • Throttling is a token bucket per seller and app: getOrders refills at 0.0167 requests per second, burst 20; getOrder at 0.5, burst 30
  • Orders older than two years are archived out of API responses, except Japan pre-orders
  • A 429 means the bucket is empty; the x-amzn-RateLimit-Limit header may be absent, so back off by time
  • Buyer names and addresses are unavailable without an RDT, and each RDT is scoped to the resources it names

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Amazon SP-API ↗

Questions and answers

Why does the connector need a Restricted Data Token?
Buyer names and shipping addresses are PII. The Tokens API issues a Restricted Data Token from POST /tokens/2021-03-01/restrictedDataToken for the restricted resources you name, such as /orders/v0/orders with the buyerInfo and shippingAddress data elements. The seller must have granted the Direct to Consumer Shipping (Restricted) role.
How fast can orders be polled?
Slowly, by design. getOrders refills at 0.0167 requests per second with a burst of 20 per seller and application pair, which works out to about one call a minute. The Notifications API exists so you do not poll: subscribe to a notification type and read the queue instead.
What does a 429 from SP-API mean?
The token bucket for that operation is empty. Each call spends one token; Amazon refills at the operation's rate up to its burst. A 429 is retryable with a back-off. Do not depend on the x-amzn-RateLimit-Limit header, which Amazon says may be missing.
Ask about Amazon SP-API

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Amazon SP-API through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy