> ## Documentation Index
> Fetch the complete documentation index at: https://routeme.sh/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Request Behavior

This page explains how RouteMesh handles your RPC requests: **allowed domains** for API keys, **cooldowns and rate limiting**, and **batch requests**.

For `eth_getLogs`, RouteMesh currently supports a maximum block range of `10,000` per request.

## Allowed domains

API keys can be restricted to specific origins (domains). When an key has **allowed domains** set, the router checks the request’s `Origin` (or Referer) header against that list. If the request comes from a domain that is not allowed, the router returns **403 Forbidden** and does not forward the request.

* **No allowed domains** (empty list): the key is allowed from any origin. Use this for server-side or mobile apps where no browser origin is sent.
* **With allowed domains**: only requests whose origin matches one of the listed hostnames are accepted. Use this for web apps to limit key usage to your front-end domain(s).

Allowed domains are configured when you create or update an API key in the dashboard. The comparison is against the request’s origin hostname (e.g. `app.example.com`), without path or scheme. This reduces the risk of a key being used from an unauthorized site.

## Cooldowns and rate limiting

When an upstream node returns a rate-limit (HTTP 429) or service-unavailable (503) response, RouteMesh puts that **pathway** (node + method) on a short **cooldown**. During cooldown, the router will not send new requests to that pathway, so you avoid hammering a node that is already overloaded.

* Cooldowns are **per pathway** (node and method), not global. Other nodes or methods are still used.
* If **all** pathways that can serve your route are on cooldown, the router returns HTTP **429 Too Many Requests** and a JSON-RPC error with code **-32003 (All nodes on cooldown)**.
* When you get -32003, **retry after a short backoff** (e.g. a few seconds). Cooldowns are temporary; once they expire, the same request can succeed.

Our aggregate capacity is high because we pool many providers. If you consistently hit cooldowns on a chain, reach out so we can help optimize.

## Batch requests

You can send multiple JSON-RPC requests in a single HTTP request by posting a **JSON array** of request objects instead of a single object. The response is a JSON array of responses in the **same order** as the requests.

* **Order**: Response index `i` corresponds to request index `i`. Use the `id` field in each request to match responses to requests if needed.
* **Partial failures**: Each batch item is processed independently. Some entries may have `result` and others `error`. The HTTP status of the batch is derived from the set of per-request statuses (e.g. 200 if any succeeded, 424 if all failed dependency, 429 if all rate limited).
* **Empty batch**: Sending an empty array `[]` is invalid and returns **400** with JSON-RPC code **-32600 (Invalid request)**.

Batch requests are a good way to reduce round-trips when you need multiple RPC calls (e.g. several `eth_call` or `eth_getBlockByNumber` in one HTTP request).

For request debugging (including `X-Batch-Id` and the Dashboard Logs page), see [Debugging](/intro/debugging).