Engineering for Amazon seller tools and commerce SaaS: SP-API and Ads API at multi-tenant scale, near real-time repricing data, and automation infrastructure.
Amazon rate limits are the product constraint
Amazon meters aggressively and unevenly. SP-API applies per-endpoint token buckets, report generation is asynchronous and queued, and limits are shared per seller account rather than per application. Features that need current data, such as repricing, Buy Box monitoring, and inventory alerts, are therefore constrained by quota rather than by your architecture. Naive polling either burns quota on unchanged data or falls behind, and both are visible to the customer as a product defect.
What we build for seller tools
- SP-API and Ads API ingestion architected around token buckets and per-seller quota, not naive polling
- Priority-based scheduling so time-sensitive data such as Buy Box and pricing gets quota first
- Change detection so quota is spent on data that actually moved
- Asynchronous report orchestration with submission, polling, retrieval, and failure recovery
- Multi-marketplace and multi-region handling with correct currency and timezone treatment
- Automation infrastructure for repricing, inventory, and advertising actions with audit trails
How we work
Model quota requirements against the freshness your features genuinely promise customers
Build prioritized scheduling and change detection before scaling tenant count
Instrument quota consumption per tenant so growth is predictable rather than a cliff
Layer automation features on the proven ingestion foundation
Typical stack
Frequently asked questions
It varies sharply by endpoint, and honest product decisions depend on knowing which. Some pricing and offer data can be near real time. Report-based data is asynchronous and typically lags by tens of minutes at best. Advertising performance restates for up to 14 days. Promising uniform real-time freshness across all of it is a promise the API cannot keep.
Quota is treated as a scarce shared resource with explicit priorities. Time-sensitive endpoints get reserved capacity, low-value polling is replaced by change detection, and consumption is tracked per tenant so you can see the ceiling approaching rather than discover it during a peak.
We have built and operated Amazon automation at multi-tenant scale, including the SellerFuse work in our case studies. The failure modes here are specific and unforgiving, and prior exposure to them is most of the value.
Yes. We build to the data protection policy requirements, including PII handling, retention, encryption, and access logging, and we have taken applications through review before. Retrofitting those controls after a rejection is considerably more expensive than designing for them.
Go deeper
Scale your Amazon integration
Tell us how many seller accounts you serve and which features depend on freshness, and we will map the architecture.
Start a project