Quick Summary An Amazon SP-API development company maintains the software that connects a seller’s Amazon account to everything else: order and inventory sync, reporting pipelines, settlement reconciliation, and dashboards. SP-API is Amazon’s REST API for orders, inventory, pricing, listings, reports, feeds, and finances. Access is secured with Login with Amazon (LWA) tokens, and Restricted Data Tokens are required for buyer data. AI agents on Amazon are only as reliable as the SP-API data layer underneath them. Amazon’s own plugin covers one account and one marketplace at a time. An SP-API development company builds order and inventory sync, reporting pipelines, reconciliation, multichannel connectors, dashboards, and the agent layer on top. Choose a partner with production SP-API experience, rate-limit handling, PII security, and a long-term maintenance plan. Most Amazon sellers have the data but no way to derive quick insights from it. Orders sit in Seller Central, inventory is split across FBA, FBM, and outside warehouses, settlement reports rarely match the books, and other channels run separately. AI agents were meant to fix this. In September 2026, Amazon opened Seller Central to agents like Claude, but its official plugin covers one account and one marketplace at a time. An agent can only answer as well as the data it has access to. That’s what an Amazon SP-API development company builds: the data layer on Amazon’s Selling Partner API (SP-API) that agents depend on. This guide covers what SP-API exposes, why it matters for AI agents, what a development partner builds, and how to choose one. What Amazon SP-API Actually Is (and What It Exposes) The Selling Partner API (SP-API) is Amazon’s REST-based API for sellers and vendors. It replaced the older MWS. SP-API is how approved applications can read and update account data in code instead of through Seller Central screens and CSV downloads. What SP-API gives you access to API What it covers Typical use Orders Orders, line items, status, shipment confirmation OMS sync, FBM fulfillment FBA Inventory / AWD Fulfillable, inbound and reserved stock Stock sync, replenishment Product Pricing Your price, competing offers, Buy Box status Repricing, price monitoring Listings Items Creating and updating listings and attributes Catalog management Reports Bulk data: sales and traffic, settlements, inventory, returns Analytics, reconciliation Feeds Bulk updates to listings, prices and inventory High-volume changes Finances Fees, refunds, financial events Profitability, accounting Notifications Event pushes such as order and offer changes Real-time triggers without polling The auth reality Every SP-API call needs a Login with Amazon (LWA) access token. When a seller authorizes an app, the app receives a refresh token, which it exchanges for a one-hour access token. Production systems refresh these automatically and store refresh tokens encrypted. A leaked refresh token exposes everything that the seller authorized. Buyer personal data is stricter. Names and shipping addresses need a Restricted Data Token (RDT), requested per operation, short-lived, and available only to apps approved for restricted roles under Amazon’s Data Protection Policy. Any FBM workflow that prints shipping labels runs into this. Rate limits SP-API rate-limits requests with a token bucket algorithm, and each operation has its own rate and burst limits. Some operations run on dynamic usage plans, whose limits can change over time. If you exceed the limit, you get HTTP 429 errors. Most throttling problems aren’t caused by one bad call. They come from systems that poll for changes instead of listening for them. Reliable builds queue requests, back off on 429s, use Reports for bulk data instead of item-by-item loops, and subscribe to Notifications for real-time events. Why SP-API Is the Foundation of the Agent Era The Amazon AI agent shift doesn’t replace SP-API. It runs on it. At Accelerate 2026 on September 23, Amazon launched a Selling Partner plugin that brings Seller Central and Seller Assistant into Amazon Quick and, in beta, Claude. Sellers grant access from a new “Manage Agents” page, choose which data types an agent can read, and approve every action before it runs. Amazon says 90% of sellers already use third-party AI for parts of their business, so the plugin formalizes something that was already happening. What the native plugin leaves out The plugin is a beta for US stores. It works on one account and one marketplace at a time and covers third-party sellers only, with no Vendor Central. It also only sees Amazon. It can’t see your Walmart orders, your TikTok Shop SKU data, your 3PL’s stock, or your accounting system. For a brand selling across several marketplaces, a 3PL managing dozens of client accounts, or a SaaS tool serving thousands of sellers, the plugin is a starting point rather than a working system. What custom agents look like Teams that need more build their own agent on top of their own SP-API data layer. The pattern looks like this: Sync: SP-API jobs pull orders, inventory, reports, and settlements into your own database, alongside data from your other channels. Expose: An MCP (Model Context Protocol) server gives Claude a defined set of tools over that data, read-only by default. Gate: Anything that changes the account, such as a price or inventory update, goes through an approval step before it is sent back through SP-API. Build: Claude Code speeds up building and maintaining these tools, but engineers design the guardrails. The agent is the new interface. Whether its answers are right still depends on the SP-API layer underneath it. What an Amazon SP-API Development Company Actually Builds Most SP-API projects are made up of the same five building blocks, combined around how a seller actually operates. 1. Order and inventory sync The problem: Stock counts drift between FBA, FBM, AWD, and outside warehouses, and overselling across marketplaces follows. What gets built: Amazon order sync through the Orders API and Notifications, with inventory pulled from the FBA Inventory and AWD APIs. One inventory management system as the source of truth, pushing stock updates to every channel with safety-stock buffers. 2. Reporting pipelines The problem: Seller Central reports are downloaded by hand, so they arrive late and come in inconsistent formats. What gets built: Scheduled reporting pipelines that request reports through the Reports API, wait for processing, then download, parse, and load them. Retries and gap detection, so a failed report doesn’t silently leave a hole in the data. 3. Settlement and fee reconciliation The problem: Amazon payouts rarely line up neatly with orders, and fees, refunds, and reimbursements are hard to trace. What gets built: Settlement reports and Finances API events matched against orders. Fees, refunds and reimbursements categorized, with discrepancies flagged. Clean entries pushed into accounting tools such as QuickBooks. 4. Multichannel connectors The problem: Amazon is one channel among several, and each channel uses different SKUs, order formats, and stock rules. What gets built: Connectors that normalize Walmart, eBay, Shopify and TikTok Shop data alongside Amazon. Routing of orders to the right warehouse, or to Amazon Multi-Channel Fulfillment where it makes sense. 5. Custom dashboards and the agent layer The problem: Once data is unified, teams need to see it and question it without exporting it first. What gets built: Custom dashboards built on the same database, showing the metrics the business actually tracks. Increasingly, an MCP layer so the team can ask questions in plain English, as in the example below. The order matters. Dashboards and agents are only as good as the sync and reporting jobs feeding them, which is why most of an SP-API project’s effort goes into steps 1 to 3. Example: SP-API agent in practice Seller Bridge AI, built by eSellerHub, shows what this looks like in practice. It connects directly to Amazon’s SP-API and pulls account data on a schedule, with rate-limit handling built in. Every account and marketplace lands in one live view: revenue, units, orders, average order value, top products, and inventory health. On top of that data, we built an MCP layer inside the seller’s backend, so the team can ask questions in plain English. “How do my sales look this week?” “How does this month compare with last month?” “Show me the order history for this SKU.” The AI reads the underlying reports and answers from the seller’s own account data, not from generic best-practice advice. How to Choose an Amazon SP-API Development Services Partner Most agencies list SP-API on their services page. Far fewer have kept an integration running in production for years. These five checks help you tell the two apart. 1. Production SP-API experience Look for a SP-API development partner that understands which roles your use case needs. A good partner knows the difference between a private app built for one seller and a public app that Amazon requires to be listed in the Selling Partner Appstore. You can opt for live integrations instead of demos while shortlisting. 2. Rate-limit engineering Throttling shows up at scale, not in testing. Look for request queuing, backoff, bulk pulls through Reports, and Notifications instead of polling. 3. RDT handling and data security If your workflow touches buyer names or addresses, your partner must handle Restricted Data Tokens and meet Amazon’s Data Protection Policy, including encryption and limits on how long buyer PII is kept. 4. A maintenance plan SP-API keeps changing. Versions get deprecated, feed types are retired, and even commercial terms move: Amazon announced developer fees for 2026, then cancelled them in May. An integration without a dedicated SP-API developer behind it breaks quietly. A partner with a long industry experience can adapt to volatile rules and regulations. 5. Agent-readiness Your data layer should be ready to sit behind an MCP server or a Claude-based agent, with scoped read-only tools and approval gates on anything that writes back to Amazon. Checklist: 12 Questions to Ask an Amazon SP-API Development Company Use these on your first call to see how a partner actually works, not just what they claim. Production experience ☐ Which of your SP-API apps are live in production today, and for how long? ☐ Have you built private apps, public Appstore apps, or both? ☐ Which SP-API roles does our use case need, and are any of them restricted? Rate limits and reliability ☐ What happens when we hit 429 errors during peak season? ☐ Do you use Notifications for real-time events, or poll for changes? ☐ How do you detect and backfill a failed or missing report? Security and data protection ☐ How do you store refresh tokens and buyer PII, and when is PII deleted? ☐ How do you handle Restricted Data Tokens for buyer data? Maintenance and ownership ☐ Who monitors SP-API deprecation notices and policy changes? ☐ What support is included after launch? ☐ Who owns the code and the developer credentials once the project ends? Agent-readiness ☐ How would you expose our SP-API data to an AI agent safely, and which actions would need approval? Conclusion: Build the Data Layer Agents Depend On AI agents have changed how sellers work with Amazon data, but not where that data comes from. Three things matter most: SP-API is the foundation: Auth, RDTs, and rate limits decide whether an integration holds up at scale. Amazon’s native plugin is a starting point: Operations that span multiple accounts, marketplaces, or channels still need a custom data layer. Agents are only as good as what’s underneath: Reliable sync, reporting, and reconciliation come first. If you’re evaluating an Amazon SP-API development company, judge it on the data layer, not the chat window. // FAQs Frequently Asked Questions What does an Amazon SP-API development company do? It maintains the software that connects a seller’s Amazon account to everything else: order and inventory sync, reporting pipelines, settlement reconciliation, and dashboards. Increasingly, it also builds the data layer that AI agents query. The work covers authentication, rate limits, data security, and long-term maintenance. Do I still need custom SP-API development if I use Amazon’s Selling Partner plugin for Claude? Often, yes. Amazon’s plugin is a US beta that works on one account and one marketplace at a time, covers third-party sellers only, and sees only Amazon data. Multi-account, multi-marketplace, vendor and multichannel operations still need a custom SP-API layer. What is a Restricted Data Token, and when do I need one? A Restricted Data Token (RDT) is a short-lived token that grants access to buyer personal data, such as names and shipping addresses. You need one for workflows like FBM label printing, and your app must be approved for the matching restricted role. Does Amazon charge fees to use SP-API? Not currently. Amazon announced an annual fee and usage charges for third-party developers in 2026, then cancelled both in May 2026. Sellers using SP-API only for their own business were never going to be charged. What’s the difference between a private and a public SP-API app? A private app connects one company’s own account to Amazon. A public app serves other sellers and must be listed in the Selling Partner Appstore, which brings extra review and data-protection requirements. Is it safe to connect AI to my Seller Central data? It can be, if access is designed carefully. That means read-only tools by default, an approval step before any change to the account, encrypted credentials, and no buyer PII without a valid RDT. Amazon’s own plugin uses a similar approval-first model. Enter your Details to Receive the Checklist ×