Rate limits

Requests per hourCopy Anchor Link

Each account can make 3,600 requests per UTC hour in each mode, or 600 before your first purchase. The count starts again at the top of every hour.

Webhook deliveries to your endpoints do not count toward it. Your own calls do, in the mode of the key that makes them.

Every request your key authenticates gets the numbers for the current hour back in three headers. A path that does not exist (route_not_found) or a wrong method (method_not_allowed) is answered before the key is read, so those responses carry none of them.

GET /account returns the same numbers in rate_limit, with the reset as a time.

Operations with their own limitsCopy Anchor Link

Uploads with file count only toward the hourly request limit.

When you hit a limitCopy Anchor Link

The API answers 429 rate_limited with a Retry-After header. Wait that many seconds, then send the same request again.

HTTP/1.1 429 Too Many Requests
Retry-After: 1460
RateLimit-Limit: 3600
RateLimit-Remaining: 0
RateLimit-Reset: 1460

{
  "error": {
    "code": "rate_limited",
    "message": "You sent 3,600 requests this hour. Try again in 1,460 seconds.",
    "doc_url": "https://submitator.com/docs/errors#rate_limited",
    "request_id": "c04d3fa7-d94d-40d0-bfc7-20614c362b82"
  }
}

Stay under the limitCopy Anchor Link

• Receive events as webhooks instead of asking for them: deliveries cost you no requests.
• Read the events feed with your last next_cursor instead of polling each project: 1 request returns up to 100 changes.
• Ask for 100 items per page with limit=100 when you read a whole list.
• Check RateLimit-Remaining before a batch, and spread a batch over the hour when it would run out.

Listings in progressCopy Anchor Link

Separate from request limits, up to 100 of your listings are in progress at once. A launch is always accepted: listings above that number wait in pending and start as others finish. GET /account shows the count in capacity.