Building Amazon seller tools with AI coding assistants: what works, what breaks

AI coding assistants have changed who builds Amazon seller tools. A founder or an operations lead can now describe a restock report or a profit dashboard to an assistant and have working code the same afternoon. This post covers what these assistants do well on Amazon's Selling Partner API, the production gaps they tend to leave open, and a checklist to run before an AI-built tool touches a live seller account. The Amazon rules below link to Amazon's own documentation, checked September 25, 2026.

What can you build with an AI coding assistant in a weekend?

Quite a lot. Anthropic describes Claude Code as an agentic coding tool that reads your codebase, edits files and runs commands, in the terminal, an IDE, a desktop app or the browser. OpenAI describes Codex CLI as a coding agent that runs locally on your computer (both checked September 25, 2026). Give either one the SP-API documentation and a clear task, and it can usually write the Login with Amazon token exchange, the report request and the parser in an afternoon.

The documentation part matters most, because a model's training lags Amazon's changes. Amazon publishes an index of its SP-API docs for AI tools, and adding .md to any docs page URL returns a Markdown version an assistant can read. In May 2026 its Selling Partner Developer Services team also posted the Local MCP for SP-API, which gives MCP-compatible tools such as Claude Desktop, Kiro, Cursor and VS Code a documentation search, code samples in five languages, a code review and a migration assistant. It sits in Amazon's samples repository, which calls its contents educational examples, not supported products (all checked September 25, 2026).

The projects that go well look like this:

These have three things in common: they read your own account, a person runs them and checks the output, and nothing breaks for customers if they fail. A prototype like this is also the clearest spec you can hand to an engineer, far clearer than a requirements document written from memory.

What breaks in production?

The demo runs on your laptop, against your account, with a token you pasted in, while you watch. Production runs on a schedule, with nobody watching, on data that can include buyers' names and addresses, for years. The code an assistant writes can be fine line by line. What goes missing is everything around it: the access Amazon has to approve, the limits it enforces, the data rules it can audit, and the dates on which calls stop working.

Some breaks are small and specific. Amazon's Flat File V2 settlement report, which replaces the older flat-file and XML settlement reports, moves fees out of their own columns into three (amount-type, amount-description and amount), and shows amounts in local currency formats, so an EU amount can arrive as 95,00 rather than 95.00 (checked September 25, 2026). A parser written for the old layout, or tested only on US data, can misread those rows, and the profit dashboard built on it drifts without an error message. An assistant fixes it in minutes once told; the hard part is knowing to tell it.

Others are business rules nobody wrote down. When we built Cheddy, a stock management tool, the difficult part was mapping kits, multipacks and single-pack ASINs to the warehouse components they use, which is why off-the-shelf software did not fit. No model knows your bundles. Whoever builds the tool has to find those rules, write them down and test them, and that work is the same with or without an AI assistant.

The production-gap checklist for AI-built seller tools

Run each row before an AI-built tool touches a live seller account. The middle column is what a weekend build usually does; the right column is what Amazon's rules, or a year of running the tool, will demand. The Amazon sources for each row are linked in the sections below, all checked September 25, 2026.

How do SP-API access, roles and restricted data work?

Before any code runs, Amazon has to let you in. A brand building for itself registers as a private developer, which Amazon defines as a company that integrates only itself, and fills in a developer profile: contact details, the roles it needs, its use cases and its security controls. Amazon evaluates the profile against the app's functionality and its Acceptable Use and Data Protection policies, and asks for answers to its questions within five days. Our SP-API registration guide walks through the steps. An assistant can draft the answers; it cannot make the security controls true.

Roles decide which operations your app may call. Four are restricted because they need sensitive information that can include buyer PII; Direct-to-Consumer Shipping is the one an order or shipping tool is most likely to meet. For those, Amazon asks for more detail about data use and security controls, and adding a role later means new authorizations and a new refresh token. Amazon's Acceptable Use Policy also tells developers not to request data their app does not need, so asking for every role to be safe is the wrong default.

Who uses the tool matters as much as what it does. A private app is for your own organization's internal use; the account's Primary User self-authorizes it, up to 10 self-authorizations. An app that serves other sellers needs a public developer registration and OAuth consent from each seller. It is capped at 25 authorizations until listed in the Appstore, and sellers must reauthorize it every 365 days and whenever it adds a role. The software we built for Little Owl, an FBA prep center, has admin and client sides because it serves many sellers. A DIY tool that reaches other sellers' accounts through the SP-API has to be registered as a public app.

Buyer data is the easiest place for AI-written code to go wrong, because the obvious call returns it. In Orders API v0, restricted operations such as getOrderAddress need a Restricted Data Token. In the new Orders API v2026-01-01 there is no token step: buyer and recipient details come back when you request includedData BUYER or RECIPIENT and hold the right role. Restricted order reports that carry buyer names and addresses, such as GET_FLAT_FILE_ORDER_REPORT_DATA_SHIPPING, still need a token (checked September 25, 2026). Whichever path you use, request buyer data only in the step that needs it, and keep it out of logs, spreadsheets and chat prompts.

How do rate limits, token refresh and deprecations catch AI-written code?

SP-API usage plans work like token buckets: each operation refills at a set rate per second up to a maximum, the burst. Most limits apply per seller and app pair, an empty bucket returns HTTP 429, and Amazon asks for a back-off strategy on repeated throttling rather than instant retries. Code written from a quick prompt can simply loop until it is done. On orders, that loop hits the wall fast: searchOrders defaults to 0.0056 requests per second with a burst of 20, and returns up to 100 orders per page (checked September 25, 2026).

Hours to page through a backfill ≈ (orders ÷ 100 per page − 20 burst calls) ÷ 20 calls per hour (for more than 2,000 orders)

The 20 calls an hour is the default rate, 0.0056 per second, times the 3,600 seconds in an hour. A 10,000-order backfill is 100 calls: the burst covers 20 and the other 80 take about four hours, while every other feature that calls searchOrders for that seller waits in the same bucket. The fix is design, not retries: read the x-amzn-RateLimit-Limit header, pace each operation against its own bucket, and use reports for bulk data and notifications instead of polling, as Amazon advises. The Acceptable Use Policy also bars extra developer accounts or apps created to get around throttling.

Tokens fail on a timer. A Login with Amazon access token lasts 3,600 seconds, so a long job has to refresh it mid-run, and every request needs a user-agent header with the app name, version and language. The app's client secret must be rotated every 180 days. Amazon sends a notice 90 days ahead, the old secret stops working seven days after you generate a new one, and after the deadline the app's calls return errors. A tool built in March stops working in September unless somebody owns that date.

The API itself moves. An assistant trained before a change may write the older call with full confidence, so check every version against Amazon's deprecation schedule. Some removals have already landed: the ORDER_STATUS_CHANGE notification, deprecated in June 2023, was removed on July 29, 2026, and ORDER_CHANGE is the order notification in Amazon's current notification type list. Three more removals matter to seller tools over the next year, and two touch the money data profit dashboards are built on (checked September 25, 2026):

What does Amazon's Data Protection Policy mean for a tool you built yourself?

Amazon reviews developer profiles against its Data Protection Policy, which covers every system that handles data retrieved through the SP-API, not only systems with buyer data. Its first section applies to every app: a unique login per person, quarterly access reviews, API credentials encrypted at rest and rotated at least every 12 months, TLS 1.2 or higher in transit, and notice to Amazon within 24 hours of a security incident. Its second section adds rules for PII, which Amazon grants only for select purposes, such as shipping orders you fulfill yourself, on a must-have basis. The policy also lets Amazon audit a developer's systems (checked September 25, 2026).

Once PII sits in a data store, the whole store falls under the PII rules, including the tables without PII. Amazon's security control guidance, updated in September 2026, lists what that means: delete PII within 30 days after order delivery, encrypt it at rest with AES-128 or RSA-2048 keys or stronger, keep security logs for at least 12 months with no PII in them, and fix critical vulnerabilities within 7 days. For a DIY tool, the cheapest control is design: keep buyer data in its own store, or out of the tool entirely.

For a tool that does handle PII, three more rules land squarely on AI-assisted work. The policy bars hard-coding credentials such as secret keys and passwords, and bars exposing them in public code repositories. It bars storing PII on personal devices or unsecured cloud apps unless it is encrypted. And it asks developers to assess vendors and subcontractors each year before giving them access to Amazon data. Our reading, which is not legal advice: if real order data goes into a prompt, the AI provider is one more vendor with access to it.

The practical answer is to keep secrets and buyer data out of the session. An agentic coding tool reads your codebase and runs commands, so treat everything in the project folder as visible to it and keep credentials in a secrets manager. Test with scrubbed samples or the SP-API sandbox, which returns mock or realistic responses without touching production data. Amazon says the sandbox tests functionality, not scale: at five requests per second with a burst of 15, it is far looser than production searchOrders, so a sync that runs cleanly there can still throttle live.

Two rules from 2026 apply once the tool acts on its own. Amazon's Business Solutions Agreement update, effective March 4, 2026, requires AI agents to identify themselves as automated systems, follow the new Agent Policy at all times and stop if Amazon asks, and restricts using Amazon materials or services for AI development (checked September 25, 2026). The announcement covers automated software as well as AI agents, so we treat any job that changes your account without a person as in scope, not only chatbots. Our Agent Policy guide goes through each rule.

Write access deserves its own gate. A listing or price change through patchListingsItem can run in VALIDATION_PREVIEW mode first, which validates the change without saving it to the catalog (checked September 25, 2026). A production tool uses that preview, checks a price floor and ceiling in code, and has a person approve changes to prices, stock and listings before they run. If you want an AI assistant to act on the account at runtime rather than only write the code, our guide to SP-API MCP servers covers which operations to expose and how to gate them.

Who maintains it next year?

The real cost of a DIY tool is not the weekend; it is the calendar after it. Amazon's security guidance lists recurring tasks developers must run to keep SP-API access, and the API adds its own dates. Each one needs a named person, because a chat history is not a runbook, and the teammate who prompted the tool may have moved on by the time a deadline arrives. This is the calendar we would hand to whoever owns the tool. The "Applies to" column follows the Data Protection Policy's own split between rules for every app and extra rules for apps that store or process PII:

If your team has an engineer who will own that list, a DIY tool can run for years, and an AI assistant makes that engineer faster. If it does not, the tool usually works until the first deadline it misses. Our comparison of an in-house team with outside help covers the staffing side of that choice.

When should you build it yourself, and when should you bring in engineers?

Build it yourself when the tool only reads your own account, a person runs it and checks the result, and no buyer data is involved. That covers most reporting, reconciliation and analysis, and the Data Protection Policy's every-app rules stay manageable for a small team. Bring in engineers when any of the triggers below apply, or when a failure would cost more than the build. Check first whether you need to build at all: Amazon's Selling Partner plugin is in beta for sellers in Amazon's US stores, and sellers review and approve its actions before they are carried out (checked September 25, 2026). Our plugin explainer covers what it reaches.

This post is about the gap between a prototype and production. For the wider choice between a subscription, a custom build and a licensed platform, read build vs buy Amazon seller software. For budgets, see what SP-API development costs, and if you plan to staff the work yourself, read how to hire an SP-API developer before you post the job.

Ecomsellertool is a tech agency that grows brands through technology; we have built on Amazon's seller APIs since 2017 and shipped 50+ tools. In SP-API development work, we start from your prototype as the spec and add the access, limits, data rules and maintenance above, on your own accounts and on top of Growth OS. You keep your accounts, your data and the custom code we build; the Growth OS base is licensed to you.

To see where software would help first in your account, start with the free 24-hour diagnostic: connect Amazon with Login with Amazon, no password shared, and get the report within 24 hours of connecting, on business days. We only read data; we never change listings, prices, stock or ads. To walk through a prototype with our engineers, schedule a call.