Skip to content

Rate limits

Checked against the API code 3 November 2026

Limits keep one busy integration from slowing down everyone else. Most integrations never reach them. This page lists the limits, what you get when you reach one and how to stay under them.

LimitCountsWindow
Per API key300 requests5 minutes
Per API key, placing orders300 requests to POST /api/v2/orders1 minute
Per IP address300 requests1 minute
Per IP address2,500 requests15 minutes
  • The key limit counts every request the key makes. The window starts with the key’s first request and lasts five minutes. Requests over the limit are refused until the window ends.
  • POST /api/v2/orders has its own budget. Orders do not use up the key’s 300 per five minutes.
  • The IP limits count every request from your address. That includes all your keys and the client area in a browser on the same network. Order requests do not count toward the 15-minute limit.
  • The IP limits are rolling. Each request counts for one window from the moment it was sent.

Some endpoints have a limit of their own on top of the ones above. These limits are rolling, like the IP limits. For requests made with an API key, each one is counted per IP address. All keys used from the same address share it, even keys of different accounts.

Domains

VPS

Web hosting

Domain availability checks also use the account’s lookup budget. It counts checked names, not requests. With an API key it is 300 checks per minute and 6,000 per hour.

  • One name with one extension is one check. A POST /api/v2/domains/availability with 50 names uses 50.
  • Searches in the client area on the same account count too.
  • The budget starts again on each full minute and each full hour.
  • Over the budget, the API returns 429 with the code rate_limit_exceeded. Retry-After is the number of seconds until the minute or the hour is over.
  • Refused checks still count. Do not check again before Retry-After has passed.
Limit reachedWhat you getWhat to do
An IP limit or an endpoint limit429 rate_limit_exceeded with Retry-AfterWait the seconds in Retry-After. Then send the request again.
The key limitMostly 500 internal_error, sometimes 429. No Retry-After.Stop. Wait five minutes before you send again.

A 429 for an IP or endpoint limit looks like this:

Response 429
{
"type": "https://developer.hostup.se/errors/rate_limit_exceeded",
"title": "Too many requests",
"status": 429,
"detail": "Too many console ticket requests. Please try again in a moment.",
"instance": "/api/v2/vps/vps_01hxa3b4c5d6e7f8g9h0j1k2m3/console",
"code": "rate_limit_exceeded",
"requestId": "0e7d4c2a-6b1f-4a9e-8c3d-5f2b7a1e9d64",
"timestamp": "2026-11-02T10:15:18.000Z"
}

With these headers:

Response headers
Retry-After: 42
X-RateLimit-Limit: 10
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 2026-11-02T10:16:00.000Z
  • Retry-After is the number of seconds to wait. Wait that long before you send the request again.
  • X-RateLimit-Limit is the size of the limit you reached.
  • X-RateLimit-Remaining is how many requests that limit still allows. It is 0 on a 429.
  • X-RateLimit-Reset is a UTC time in ISO 8601, not a Unix timestamp. On a 429 it is when your oldest counted request expires. One more request fits then, not the whole limit. On other responses it is one window from now.

Every response under /api/ carries the three X-RateLimit-* headers, not only a 429. They describe whichever IP or endpoint limit is closest to running out for that request. They do not show the key’s own budget of 300 per five minutes. Count your key’s requests yourself if you run close to it.

A request refused with rate_limit_exceeded changed nothing. It is safe to send again after the wait.

The key limit does not return 429 with Retry-After today. When a key goes over its 300 requests, most endpoints return 500 with the code internal_error. A few return 429 with a short body that has "code": "API_KEY_RATE_LIMIT_EXCEEDED". The MCP server at /mcp returns 429 with a JSON-RPC error. None of them has Retry-After. On /api/ endpoints the X-RateLimit-* headers describe the IP limit, not the key.

If many calls in a row fail with 500 after a burst, stop and wait five minutes before you send again.

GET /api/jobs/{jobId} is outside /api/v2. Its 429 for an IP limit has a different body: error, message, retryAfter (an ISO time) and requestId. There is no code. The headers are the same. Check the status and Retry-After, not the body.

Not every 429 is about how many requests you send. Read code before you send the request again.

  • Poll jobs every 3 to 5 seconds, not faster. One job polled every 4 seconds uses 75 of the key’s 300 requests per five minutes. When you follow more than three jobs at once, poll each one less often. Jobs
  • Ask for big pages. Most lists take limit=100. Pagination
  • Use the bulk domain endpoints for changes to many domains, not one call per domain.
  • When you work on many resources, send a few requests at a time at most. Do not send everything at once.
  • On 429, wait as Retry-After says. Retrying at once only adds to the count.

Next: Versioning