Skip to main content

Rate limit

Your account may make one API request per second, across both endpoints; console searches and MCP server calls count against the same limit. A refused request uses no search. Over the limit, the API answers 429 with Retry-After: 1:
Space requests one second apart, or wait for Retry-After and retry on this error. There is no burst allowance. Requests are also capped at ten per second per IP address, before the key is checked, so several keys used from one machine share that ceiling. Over it, the API answers 429 with the code ip_rate_limited and Retry-After: 1.

Monthly searches

Every search request (GET /v1/apps?q=…) that runs a search counts against your account’s monthly allowance: 3,000 searches on Plus, shared with your console and MCP searches. Each page is a separate search, so reading pages 1 to 3 of a query uses three. The allowance resets at 00:00 UTC on the 1st of each month. A request with a missing or blank q answers 400 query_required and uses no search:
A q that reads as nothing, such as status:2oo alone, returns an empty page whose query is "" and uses no search either. Once the allowance is used up, search answers 429 until the next reset:
This 429 has no Retry-After: retrying will not help before the 1st. Stop searching until then; GET /v1/apps/{hostname} keeps working. See Plans and limits for what counts. The has:creds filter always applies to API queries: API access and the filter are both part of the Plus plan. A search is used only when a GET /v1/apps?q=… request has passed every check, the monthly limit included, and the search has started.
  • Never use one: GET /v1/apps/{hostname}, a q that reads as nothing, and every 400 (a missing or blank q included), 401, 403, 404, 405 and 429.
  • Use one: a 502, 503 busy or 504 from a search once it has started. Count it as used. A 504 is remembered for a minute: retrying the same query and page within that minute returns the same 504 and uses another search.
  • 503 maintenance uses none: the request never reached Periphery.

Error format

Errors are JSON objects with two strings, a human-readable error and a stable code:
Switch on code, not on the message: messages may change, and new codes may be added. Error responses carry Content-Type: application/json and Cache-Control: no-store, like every other response.
Any response other than 200 means the result is unknown. Never read an error as “no results”: an empty result is a 200 with "hits": [].

Error codes

Search can also answer 403 plan_required with the has:creds filter requires the Plus plan; no plan with API access triggers it today. Successful responses are 200 with the JSON body described on each endpoint page.