Errors

The gateway speaks two error vocabularies at once:

HTTP status codes for transport problems (auth, throttling, our own infrastructure being unhappy).
JSON-RPC error envelopes for problems with the call itself (bad params, method not supported, reverted contract).

A response with HTTP 200 and a JSON body containing an error field is not a transport failure. It's a JSON-RPC error that you handle like any other reply.

HTTP status codes

Status	Meaning	What to do
`200`	Request reached an upstream. Inspect the body.	Check for `error` in the JSON-RPC envelope.
`400`	Malformed request. Missing JSON body, broken JSON, etc.	Fix the client.
`401`	Missing or unknown api key.	Verify the key, check it isn't revoked.
`403`	The key is known but not allowed (revoked, or accessing a forbidden surface).	Re-issue the key or check scopes.
`404`	Wrong path. Chain slug or architecture doesn't exist.	Check chains for valid slugs.
`429`	Rate limit hit. `Retry-After: 1` header is included.	Back off. See rate limits.
`502` / `503`	No healthy upstream for this chain, or all upstreams refused.	Retry once. If persistent, check status.
`504`	Upstream took too long.	Retry, or narrow the query (especially for `eth_getLogs`). See endpoints / timeouts.

We do not return 5xx lightly. The gateway retries internally before surfacing a 5xx, so if you see one your client retry should be brief and bounded.

JSON-RPC errors

When the upstream answers but the call itself failed, you get HTTP 200 with an error envelope:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32602,
    "message": "invalid argument 0: hex string has length 5, want 40 for common.Address"
  }
}

Standard JSON-RPC error codes you'll see most often:

Code	Meaning
`-32700`	Parse error. Body wasn't valid JSON.
`-32600`	Invalid request envelope.
`-32601`	Method not found on this chain.
`-32602`	Invalid params (most contract-call mistakes land here).
`-32603`	Internal error from the upstream.
`-32000` to `-32099`	Application-defined errors (e.g. EVM `execution reverted`). The `message` and optional `data` carry the detail.

The message string comes straight from the upstream node; we don't normalize it. If you need to programmatically branch on a revert reason, parse error.data or the message string in your client.

Distinguishing the two

A robust client checks both:

const res = await fetch(url, { method: "POST", body, headers });
 
if (!res.ok) {
  // HTTP-level: 401, 429, 5xx, etc.
  if (res.status === 429) {
    // back off
  }
  throw new TransportError(res.status, await res.text());
}
 
const payload = await res.json();
 
if ("error" in payload) {
  // JSON-RPC-level: bad params, revert, method not found
  throw new RpcError(payload.error.code, payload.error.message);
}
 
return payload.result;

When to retry

Failure	Retry?
HTTP `429`	Yes, after `Retry-After` plus jitter.
HTTP `502` / `503` / `504`	Once, with a short delay.
HTTP `4xx` other than 429	No. Fix the request.
JSON-RPC `-32000` to `-32099`	No. The contract or app returned an error.
JSON-RPC `-32601` (method not found)	No. The chain doesn't expose this method.
JSON-RPC `-32603` (internal upstream error)	Once. If persistent, it's usually a temporary upstream issue.

Live status

For incidents and ongoing degradations, check the public status page:

https://endpoint.originstake.com/status

It updates every minute with per-chain health and recent error rates. If your traffic is failing and the status page is green, open the dashboard's usage panel to see if the errors are scoped to your key.