Rate limits
What is metered, how it is counted, and what to do when you hit a limit.
Limits exist to keep expensive work honest. They are counted per connection when a call is authenticated, and per IP when it is anonymous, so a shared office network is not one bucket for one person.
Published limits
check_launch_readiness10 per hourAlso POST /api/v1/launch-readiness/. Every call performs an outbound crawl of somebody else's site and a model
call to draft the listing, which makes it by far the most expensive thing here. Counted per connection, or per IP
when anonymous.
Readsgeneroussearch_products, get_product and list_launch_directories, and their GET equivalents, are not metered per
account. They are protected against abuse at the edge, so a normal agent session will never see a limit and a
scraper hammering the catalog will.
Writeslow by designsubmit_product and POST /api/v1/submissions/ are limited to a small number per window. A maker opens a handful
of drafts a month; anything past that is a mistake or a bot.
Only the readiness limit is a documented number, because it is the only one you can plausibly reach by using the API as intended. The others are set to catch abuse and can change without notice. Do not build a client that depends on a specific value.
When you hit one
Both transports answer with TOO_MANY_REQUESTS, which is a 429 over REST. Treat it as "come back
later", not as a failure of your request: nothing was created, so a retry is safe.
{
"error": {
"code": "TOO_MANY_REQUESTS",
"message": "Rate limit reached. Try again in 42 minutes."
}
}Staying under them
- 1
Audit once, not once per attempt
The readiness audit is the metered one. Run it, fix everything it names, then rerun once to confirm. Running it after every small edit is what burns ten calls in an afternoon.
- 2
Cache reads in your own process
Catalog data changes weekly, not by the second. If your script walks 200 products, hold the result rather than refetching per iteration.
- 3
Back off on 429 rather than retrying immediately
Wait, then retry once. A tight retry loop turns a one hour pause into a longer one.
- 4
Use one connection per client, not per run
A connection is bound to your account and stays valid until you revoke it at /profile/connections/. Creating a fresh one per script run gives you no extra quota and clutters the list.