How to Hire an Amazon SP-API Developer (Without Getting Burned)
The Selling Partner API looks like a normal REST API on the docs page. In production it is a maze of throttling rules, asynchronous report queues, restricted data tokens and region-specific quirks — which is why generic backend developers routinely underestimate it, and why so many seller tools get built twice. Here is what to look for before you sign anyone, based on what we’ve seen building SP-API software since 2017.
The skills checklist
A developer who has genuinely shipped SP-API software can talk fluently about:
- LWA authorization flows — self-authorization for private apps vs the OAuth website workflow for public apps, and when Amazon’s app review applies.
- Rate limits and burst budgets — per-endpoint token buckets, and how to design queues so a big seller’s catalog sync doesn’t starve everything else.
- The Reports API lifecycle — request, poll, download, decompress, parse; and what to do when a report silently comes back CANCELLED.
- Restricted Data Tokens — required for PII like buyer addresses; a developer who has never needed one has never shipped order fulfilment software.
- Notifications (SQS/EventBridge) — event-driven syncs instead of hammering endpoints on a cron.
- Marketplace differences — NA/EU/FE endpoints, currencies and tax documents if you sell in more than one region.
Agency vs freelancer vs in-house
| Option | Best when | Watch out for |
|---|---|---|
| Freelancer | Small, well-defined single integration with a tight budget | Bus factor of one; SP-API experience is hard to verify; maintenance after handover |
| In-house hire | The tool IS your product and needs daily iteration for years | $100k+/yr commitment before you know the product works; long ramp-up on SP-API quirks |
| Specialist agency | Fixed scope, fixed quote, production experience from day one | Make sure you own the code and the AWS/LWA credentials — insist on it in writing |
| White-label licence | A proven platform already does most of what you want under your brand | Confirm source code handover and licence terms up front |
Five interview questions that filter fast
- “How do you handle a 429 QuotaExceeded on the Orders API?” — listen for token buckets, backoff with jitter and queue design, not just “retry”.
- “Walk me through getting buyer PII for shipping labels.” — must mention Restricted Data Tokens and the data protection policy.
- “How would you sync 100k SKUs daily without breaking limits?” — reports over per-item calls, notifications over polling.
- “Public or private app for this project, and why?” — tests whether they know Amazon’s review process at all. (Our registration guide is the 5-minute primer.)
- “Show me something you’ve shipped on SP-API.” — a live product, a portfolio, or a walkthrough. No artifacts, no hire.
Red flags
- Quotes a full platform without asking about marketplaces, SKU counts or public-vs-private.
- Talks about MWS as if it were current (Amazon shut it down — everything is SP-API now).
- Won’t put code ownership and credential handover in the contract.
- No plan for API version deprecations after launch.
Building part of it yourself with Claude Code, Codex or another AI coding assistant? Our guide to building Amazon seller tools with AI lists the SP-API rules those assistants tend to miss.
What working with us looks like
We are the specialist-agency column of that table: fixed scope and a fixed quote. You keep your accounts, your data and the custom code we build; the Growth OS base is licensed to you. See how our custom SP-API development works, browse the portfolio, or check what SP-API development costs before you talk to anyone — including us. To shortlist other firms too, our disclosed list of Amazon SP-API development companies says what each one builds.
Talk to an SP-API team, not a sales rep
Book a call with the engineers who would actually build your tool — bring your hardest question.
