4 ways to connect Amazon Seller to Claude in 2026 (the easy way)

Prerequisites

• A Porter Metrics account with your Amazon Seller account connected (free tier is enough to try it end-to-end)
• A Claude account — the free plan works for Claude Web; a Pro subscription is needed for Claude Code and Desktop MCP features
• Admin or standard access to the Amazon Seller seller accounts you want to connect

Connect Amazon Seller to Claude with MCP

For this tutorial we’re going with the MCP method. Here’s a quick explainer of what MCP is and why it’s the best path for Amazon Seller.

MCP (Model Context Protocol) is the open standard that lets AI tools like Claude, ChatGPT, Claude Code and others access and use external APIs — the things that make tools like Amazon Seller work under the hood. Instead of building a custom integration for every AI tool you use, you install one MCP and every compatible AI gets access to the same data.

The full setup takes under 5 minutes and breaks into three moves: connect Amazon Seller to Porter, point Claude at the Porter MCP, and ask your first question.

1. Connect your Amazon Seller data to Porter

Porter sits between Amazon’s Selling Partner API (SP-API) and Claude. It handles OAuth, rate limiting, pagination and all the plumbing so Claude only ever sees clean, structured data.

Sign up for Porter. Create a free account at portermetrics.com. The free tier is enough to run this full workflow end-to-end.

Connect your Amazon Seller Central profile. In Porter, click Create → pick Claude as the destination → select Amazon Seller as the source → sign in with Amazon to grant access to your seller accounts.

Select your seller accounts. Choose the Amazon Seller seller accounts you want Claude to query. When you select multiple seller accounts under a single connection, Porter automatically blends their data together so you can query them as one.

Optional: enable automatic BigQuery storage if you’re connecting multiple seller accounts with large data volumes. This keeps Claude’s responses fast even at scale.

2. Connect the MCP to Claude

Porter’s MCP URL is what you paste into Claude. Once added, Claude can query Amazon Seller data on demand in any conversation.

Go to claude.ai and click the + icon in the chat input to open the tools menu.

In the menu that opens, hover over Connectors and click Manage connectors.

In the Connectors panel, click the + button at the top of the list to start adding a new connector.

Pick Add custom connector from the dropdown that appears.

A dialog opens with the name and URL fields. Type Porter in the first field to name the connector.

In the second field, paste https://mcp.portermetrics.com/mcp. Leave the advanced settings alone.

Click Add at the bottom right of the dialog. Claude opens a sign-in window — use the same Google account linked to your Porter workspace and approve access.

Once the authorization finishes, you’ll see Porter’s read-only tools appear in the connectors panel. You’re ready to start asking questions.

For a fuller walkthrough with screenshots at every step, see the Porter MCP tutorial.

3. Start building questions and dashboards

With Porter connected, open a new Claude chat and ask anything about your Amazon Seller in plain English. Claude calls Porter behind the scenes, pulls live data from Amazon, and answers with tables, charts, or summaries.

Try one of these to verify the setup is working:

For a full catalogue of copy-paste prompts organized by use case (agencies, DTC brands, FBA/FBM operations, cross-channel), jump to the prompts section below.

Alternative ways to connect Amazon Seller to Claude

MCP is the path we just walked through — and the one we recommend for most marketers. But it’s not the only way to get Amazon Seller data in front of Claude. The most common alternatives are Amazon Seller’s direct API (or its official MCP if it has one), a live Google Sheets bridge, and BigQuery for scale. Each has its trade-offs — pick the one that fits how your team already works.

• 🔌 Amazon Seller’s direct API (or official MCP) — Talk to Amazon’s Selling Partner API (SP-API) yourself, or install Amazon Seller’s native MCP if one exists. Maximum control, but you handle auth, rate limits and pagination — and you only get one source.
• 📊 Google Sheets — Live Sheet or one-off CSV upload. Auditable, familiar, faster for big exports — but aggregation happens in the Sheet, not the API.
• 🗄️ Google BigQuery — For large seller accounts or agencies running multi-seller account analysis. BigQuery aggregates; Claude only queries pre-built summaries.

Via Amazon Seller’s direct API (or official MCP)

If you’re building a product around Amazon Seller — or you’re a developer who’d rather own every layer of the integration — the most direct path is talking to Amazon’s Selling Partner API (SP-API) yourself. Amazon doesn’t ship an official MCP for Seller Central yet, so this means writing API calls directly in Claude Code or in your own scripts. You’ll need to follow Amazon’s rate limits & quotas and request Developer Token / API access where applicable. Either way, you skip Porter entirely and call Amazon from your own code or from Claude Code with raw HTTP requests.

Via Google Sheets (live Sheet or manual CSV)

If your team already lives in Google Sheets — or you want a paper trail before Claude touches anything — feed Amazon Seller into a Sheet, then let Claude read the Sheet. You can automate the Amazon Seller → Sheets pipeline with Porter so it refreshes daily, or do one-off CSV exports from Seller Central’s native UI for static analysis.

Via Google BigQuery (for scale)

This is the path most people overlook — and it’s the one that saves you when your Amazon Seller seller account gets serious. A single large seller or an agency managing 10+ seller accounts will hit API rate limits and latency problems querying Claude directly. Claude will literally tell you it’s taking too long or timing out on big pulls.

BigQuery fixes that. You load Amazon Seller data into BigQuery tables on a schedule, then connect BigQuery to Claude — either through a BigQuery MCP or via Claude Code with SQL queries. Instead of asking Claude to pull raw Amazon Seller data, you let BigQuery aggregate into small, optimized tables, and Claude only queries the summarized output. Scale problem solved.

Read the full BigQuery tutorial →

Connecting Amazon Seller to Claude Code

Most marketers lump Claude and Claude Code together and miss the biggest advantage of the entire MCP ecosystem. They’re not the same tool — and the difference matters enormously once you start working with Amazon Seller data seriously.

Claude is a chat interface. You ask a question, Claude pulls live data through the MCP, answers, maybe builds a quick dashboard inside the conversation. Great for one-off analysis. The problem: everything is ephemeral. Want to refresh the dashboard tomorrow? You regenerate it from scratch. Want the same report every Monday? You re-ask the question every Monday.

Claude Code is Claude running inside your computer’s terminal. Because it has access to your filesystem, runtime, and other developer tools, it doesn’t just answer questions — it can build real software. Persistent scripts, scheduled routines, HTML apps, internal dashboards, integrations that run 24/7 without your input. Once it’s connected to Porter’s MCP for Amazon Seller, a whole category of work becomes possible.

What Claude Code unlocks that Claude alone cannot

Bottom line: Claude is for quick questions and ad-hoc dashboards. Claude Code is for building apps, live dashboards, alerts, and actual tools — anything you want to run on its own without re-asking. Same Porter MCP URL works in both, so you don’t pick once and lock in.

Use cases — what you can actually do once Amazon Seller is connected to Claude

Getting the connection right is half the battle. The real value shows up in what you do next. Here are the use cases Porter users build around their Amazon Seller data — from simple Q&A to full client-facing workflows.

1. Chat and ask questions directly

The simplest use case — and still the one 80% of marketers start with. Open Claude, ask a question, get an answer grounded in live data.

It’s the fastest way to replace a daily Seller Central check-in. But chat is table stakes — the interesting use cases come next.

2. Blend Amazon Seller with your revenue data (Meta Ads, Google Ads, Klaviyo)

This is where a 360° view gets real. When you connect Amazon Seller and your revenue source (Meta Ads for retargeting, Google Ads for search campaigns, Klaviyo for post-purchase email flows), Claude can map Amazon orders to actual repeat purchases or cross-channel attribution — using ASINs, order dates, and customer segments — and give you revenue attribution that no platform-side number can.

Claude handles the ASIN and date mapping and joins. You get a client-ready revenue attribution report that no single platform can generate on its own.

3. Automated alerts and notifications on Slack or Gmail

With Claude Code you can turn Amazon Seller monitoring into a routine that runs on its own. Hook Porter’s MCP (for the data) together with a Slack or Gmail MCP (for delivery), then write a Claude Code scheduled task that pulls performance every morning and pings you only when something actually needs attention.

No dashboards, no daily check-ins. The report comes to you — and only when it matters.

4. Client-ready presentations with live data (Gamma, HTML, PDF)

A common agency pain: you send clients a Seller Central reports link, Looker breaks, the client panics — and you spend an hour explaining a broken dashboard. With Claude you can build the presentation itself — as a Gamma deck, a custom HTML page, or a PDF — populated with live numbers each time.

The presentation becomes a delivery artifact you send to the client, not a dashboard that depends on another tool staying up. No broken iframe, no login prompts, just the content.

Amazon Seller fields and metrics you can query with Claude

Before you start writing prompts, it helps to know what data is actually available. Porter MCP gives Claude access to 133 Amazon Seller fields and metrics across every reporting level, plus breakdowns by date, fulfillment channel, marketplace, and order status. And the same MCP URL also unlocks 25+ other sources — so Claude can blend Amazon Seller with Google Ads, GA4, Shopify, HubSpot and more in a single prompt.

Date

DateDay of week (Mon – Sun)Hour of dayMonthQuarterWeekYearMonth and year

Orders

Amazon Order IdBuyer Invoice PreferenceCba Displayable Shipping LabelCurrency codeEarliest Delivery DateEarliest Ship DateEasy Ship Shipment StatusElectronic Invoice Status

Items

ASINCOD FeeCOD Fee DiscountCondition IdCondition NoteCondition Subtype IdDeemed Reseller CategoryIoss Number

FBA Inventory

Inventory Last Updated TimeCarrier Damaged QuantityCustomer Damaged QuantityDefective QuantityDistributor Damaged QuantityExpired QuantityFC Processing QuantityFulfillment Network SKU

Shipping Addresses

Shipping Address Line 1Shipping Address Line 2Shipping Address Line 3Shipping Address Address TypeShipping Address CityShipping Address Country CodeShipping Address Country NameShipping Address County

Buyers

Buyer CountyBuyer EmailBuyer NameBuyer Purchase Order NumberBuyer Tax Company Legal NameBuyer Taxing Region

Sales

Average Unit PriceOrder CountOrder Item CountTotal SalesUnit Count

Listing Items

Listing Created DateListing Item StatusMain ImageMain Image URL

Sellers

Seller Display Name

Prompts you can copy-paste today

1. For agencies managing multiple Amazon accounts

Use these when you need cross-account rollup, client-ready reports, or profit-leak detection across multiple brands.

2. For DTC brands & wholesale sellers

Use these when you focus on inventory turns, Buy Box win rate, and listing optimization for ASINs.

3. For e-commerce teams running FBA and FBM operations

Use these when you monitor ship deadlines, unshipped items, and fulfillment channel split to avoid late shipments.

4. Cross-channel

Use these when you want to blend Amazon Seller with other Porter connectors in a single Claude conversation.

Limits, auth, and best practices for Amazon Seller via Claude

This is the most common “horror story” in the Amazon Seller API ecosystem — not bans, but self-inflicted downtime from throttling. A seller or agency running parallel API calls to “get everything faster” triggers Amazon’s token-bucket rate limiter, receives HTTP 429 responses, and loses hours of data sync during critical selling periods. The cost isn’t a suspended account; it’s missed restocks, stale inventory counts, and blind decision-making during high-traffic events. Unlike Meta or TikTok, Amazon does not ban you for using an MCP or Claude with SP-API — but it will silently slow you to a crawl when you exceed the documented request rates.

A secondary data-quality risk: sellers relying on SP-API for competitor pricing often miss bundle ASINs because the API returns incomplete child-variation data. One seller reported making pricing decisions on incomplete competitive data, undercutting a bundle they didn’t fully understand, and losing margin for weeks before catching the blindspot.

Amazon’s SP-API enforcement is quota-based and algorithmic, not tool-based. Amazon does not ban or throttle accounts because you used Claude, an MCP server, or Porter Metrics. It throttles because of how the API was used: burst request rates exceeding the token-bucket limits per endpoint, concurrent connections from a single app, or GET requests with non-zero Content-Length headers (which the API rejects). Read-only usage within the documented per-second and per-account limits is safe. Parallel API bursts, aggressive polling intervals, and browser automation masquerading as API calls are not. Amazon returns HTTP 429 (Too Many Requests) with a Retry-After header; repeated violations can trigger temporary suspension of API access for that specific application, not the Seller Central account itself.

The two ways to burn through your Amazon Seller quota

After reviewing official docs and community threads, two patterns come up again and again.

1. Parallel API bursts and aggressive polling. Sending multiple simultaneous requests to the Orders API or Listings API to “speed up” data retrieval. Amazon’s token-bucket algorithm tracks requests per second per account-application pair; exceeding the burst limit (e.g., 20 for searchOrders, 30 for getOrder) triggers immediate HTTP 429 throttling. Why it fires enforcement: The algorithm detects the burst pattern and reduces your available request tokens to zero. Cita oficial: Amazon SP-API Orders API Rate Limits — searchOrders: 0.0056 requests/second, burst 20; getOrder: 0.5 requests/second, burst 30. What to do instead: Use sequential requests with exponential backoff, or rely on an MCP server that implements request queuing automatically.

2. Browser automation and screen scraping instead of SP-API. Using tools like Selenium, Puppeteer, or Claude Code to programmatically click through Seller Central. Why it fires enforcement: This violates Amazon’s Terms of Service for Seller Central access. Amazon detects non-human interaction patterns (rapid page transitions, headless browser signatures) and can suspend Seller Central login access or flag the account for review. Cita: Amazon Selling Partner API Models — GitHub — official SP-API is the only supported programmatic interface; screen scraping is explicitly prohibited in Seller Central TOS. What to do instead: Route all programmatic queries through the official SP-API with proper IAM credentials and OAuth tokens.

3. Relying on incomplete Catalog API data for competitive decisions. The SP-API Catalog Items endpoint returns structured product data, but bundle ASINs and complex parent-child relationships may not surface all child variations or complete pricing context. Why it causes damage: Sellers make pricing and inventory decisions on partial competitive data, leading to margin erosion or stockouts on unseen variations. This is not an Amazon enforcement issue — it’s a data-quality trap. Cita: SupplyKick — Amazon Seller Pain Points — “incomplete data from APIs” cited as a top operational risk for scaling sellers. What to do instead: Cross-reference Catalog API data with manual spot-checks on high-stakes ASINs, or use an MCP that surfaces the Main Image URL, Item Price, and Is Prime fields alongside external validation.

Both behaviors trigger quota-based throttling and temporary API access suspension. If you want to use Claude for Amazon Seller safely, stay inside documented rate limits, never scrape, and validate competitive data before acting on it.

The 5-rule scaling protocol

Based on Amazon’s documented rate limits and quotas and the behaviors that have actually caused throttling — not guesswork:

• Stay under the per-endpoint request rate. The Orders API searchOrders endpoint allows 0.0056 requests per second with a burst limit of 20; getOrder allows 0.5 requests per second with a burst limit of 30 (Amazon SP-API Orders API Rate Limits). Exceeding these triggers HTTP 429 throttling that can cascade into hours of sync downtime. Porter MCP enforces these limits at the platform level with built-in request queuing.

• Respect the Catalog Items API static rate of 2 requests per second per account-application. The Catalog API has a hard limit of 2 req/sec per account-app pairing and 250–500 requests per application depending on the specific endpoint (Amazon SP-API Catalog Items API Rate Limits). This is the tightest bottleneck in the SP-API suite; aggressive product lookups will hit the wall fast. Cache catalog metadata for at least 24 hours unless actively monitoring new listings.

• Never send a Content-Length header on GET requests. Amazon’s SP-API returns 400 Bad Request if a GET call includes a non-zero Content-Length header (Amazon Selling Partner API Models — GitHub). This is a subtle technical trap for developers wrapping the API in custom scripts or MCP layers. Porter’s MCP implementation strips this header automatically on all GET operations.

• Cache non-volatile data for at least 1 hour. Amazon recommends caching SP-API responses for a minimum of 1 hour for data that does not change frequently (inventory levels, catalog metadata, pricing snapshots) to avoid burning quota on redundant calls (Surpass.biz — SP-API Complete Guide). A seller polling inventory every 5 minutes burns 288 requests/day on a single SKU; with a 1-hour cache, that’s 24 requests — a 12× efficiency gain.

• Limit seller authorizations to 25 per application in beta mode. During the SP-API developer beta, Amazon restricts each application to a maximum of 25 seller authorizations (Amazon Selling Partner API Models — GitHub). Agencies managing multiple Seller Central accounts must register separate applications or request production-level authorization increases. Porter MCP handles multi-account routing through its universal connector architecture, abstracting this complexity from the end user.

What Porter MCP does differently: it enforces these rate limits and safeguards at the platform level, not the user level. Porter’s Amazon Seller MCP connector is read-only by default — it cannot write listings, modify prices, or change inventory through the API, eliminating any risk of accidental data mutation. It implements per-endpoint request queuing with exponential backoff that respects the token-bucket algorithm: Orders API calls are paced to 0.0056 req/sec, Catalog Items calls to 2 req/sec, and Listings Items calls to 5 req/sec per account-app. Porter caches SP-API responses for 1 hour on non-volatile endpoints, reducing redundant quota burn by up to 90%. The connector requests only the minimal IAM scopes required (read-only orders, inventory, and catalog data) and never accesses write scopes or PII-heavy endpoints like Buyer Email unless explicitly configured. That’s the behavior Amazon’s automated systems handle gracefully — steady, scoped, read-only traffic within documented limits.

Frequently asked questions