We build SellerQI, a tool that scans Amazon seller accounts and flags problems before they cost money. Lost buy box, overcharged fees, listings that quietly lost their top keyword. Most of that data already exists inside Amazon. The hard part was never "can we get it," it was "can we read it fast enough, often enough, and turn it into something a seller can act on in under a minute."
Here's what that actually looked like, and a few things we got wrong along the way.
Read-only by design, not by accident
The first decision we made was to never write anything back to a seller's account. SellerQI connects through Amazon's Selling Partner API in read-only mode. We don't touch listings, campaigns, or settings.
This wasn't just a trust decision, though it helps with that too. It also simplified the architecture a lot. We didn't have to build rollback logic, conflict resolution, or approval workflows for actions we might take on someone's behalf. We just had to be right about what we found and clear about what to do next. The seller stays in control of every change, which also means our error surface is much smaller than it would be for a tool that edits things automatically.
If you're building on top of a marketplace API where the data is sensitive and the stakes are real money, I'd think hard before giving your app write access, even if the feature seems useful. You can usually get 80% of the value by just reading well and explaining clearly.
Rate limits shape your whole pipeline
SP-API rate limits vary by endpoint and by seller account size, and they are not generous if you're trying to do a full account scan. Early on we tried to pull everything in one pass per account. That fell apart the moment we had a few accounts with thousands of ASINs.
What worked better:
Splitting the scan into independent jobs per data type (listings, PPC, fees, returns, inventory) so a slowdown in one doesn't block the others
Queuing with backoff instead of retrying immediately on a 429
Prioritizing by what's most likely to have changed, so an account doesn't wait behind a full re-scan just to catch one flipped setting
Caching aggressively for anything that doesn't change hour to hour, like historical transaction records
None of this is exotic. It's just the kind of thing you don't think about until your first real customer has 12,000 SKUs and your naive scanner takes six hours.
Ranking by dollar impact turned out to be the actual product
We didn't set out to build a ranking algorithm. We set out to build a scanner. But once you're flagging dozens of issues a day per account, "here's a list of problems" isn't useful on its own. Sellers already know they have problems. What they don't know is which one is costing them the most this week.
So every issue gets scored by estimated monthly cost or recoverable amount, using account-specific data like current CVR, spend, and historical baselines rather than fixed thresholds. A CVR drop from 20% to 18% might be nothing on a low-traffic listing and thousands of dollars a month on a high-traffic one. The ranking has to be relative to that specific account, not a generic rule.
This ended up being where most of our engineering time actually went, not the scanning itself.
Alerts need a very short list of things worth interrupting someone for
We send alert emails for things like buy box loss, negative reviews, and inventory issues. Early versions of this alerted on almost anything unusual, and it trained users to ignore the emails within a week.
We cut the list down hard and kept it to things where a delay of even a day has a real cost. Everything else lives in the dashboard for when someone actually wants to dig in. If you're building any kind of monitoring product, I'd treat your alert list as something to prune constantly, not something to grow. An alert that gets ignored is worse than no alert at all, because it teaches people to ignore the next one too.
Grounding an AI assistant in account-specific data
We also built an assistant (we call it QMate) that answers questions using the seller's actual account data rather than general Amazon advice. The interesting part technically wasn't the model, it was making sure the answer is traceable back to a real number. If a seller asks why sales dropped, the answer needs to point at an actual CVR change, an actual image edit date, an actual keyword that disappeared from a listing. Generic advice is easy to generate and mostly useless. Grounded answers take a lot more plumbing: pulling the right slice of account history, matching timestamps across data sources, and being honest when the data doesn't clearly explain the drop.
A few takeaways if you're building on a marketplace API
Read-only access is a smaller, saner starting point than most people assume
Rate limits will define your architecture more than your feature list will
Ranking and prioritization can end up being more valuable than the raw data collection
Fewer, sharper alerts beat comprehensive ones
If you're layering AI on top of account data, grounding matters more than fluency
Happy to go deeper on any of these, especially the SP-API rate limiting piece, if people want to hear more about how the job queue is structured.
SOCIAL SHARE CARD GENERATOR