MCP and REST share a single daily request limit per account. Every response carries headers so you can track usage, and errors follow a consistent JSON shape.

## Daily limits

One counter covers both MCP tool calls and the REST API. It resets at **00:00 UTC**.

| Plan | Requests / day | Scope |
|---|---|---|
| Free | 100 | MCP + REST combined |
| Pro | 10,000 | MCP + REST combined |

Need more? [Compare plans](/pricing).

## Rate-limit headers

Every counted response includes these headers:

| Header | Meaning |
|---|---|
| `X-RateLimit-Limit` | Your plan's daily request limit. |
| `X-RateLimit-Remaining` | Requests left today. |
| `X-RateLimit-Reset` | Unix time (seconds) when the counter resets — next UTC midnight. |
| `Retry-After` | Seconds to wait — sent only on a `429`. |

## When you hit the limit

Over the limit, the MCP server returns a normal tool result whose text explains the limit and links to upgrade — so your agent can relay it in the conversation rather than surfacing an opaque transport error. The REST API instead returns `429 Too Many Requests` with the error envelope below.

```json
{ "error": { "code": "rate_limited", "message": "Daily call limit exceeded.", "status": 429 } }
```

## Error format

Every non-2xx REST response uses the same envelope:

```json
{
  "error": {
    "code": "not_found",
    "message": "Stock not found.",
    "status": 404
  }
}
```

| Status | Code | Meaning |
|---|---|---|
| 400 | `invalid_parameter` | A query parameter is missing or malformed. |
| 401 | `unauthorized` | Missing or invalid API key. |
| 404 | `not_found` | No matching resource. |
| 429 | `rate_limited` | Daily limit exceeded — retry after reset. |
| 500 | `internal_error` | Something went wrong on our side. |

Every tool and endpoint is available on every plan, so you won't see a `403` from the REST API. The MCP server returns `403` only when an OAuth token is missing the required `mcp` scope — re-run the connector's sign-in to fix it.

## Retries & idempotency

Every endpoint is a read-only `GET`, so all requests are **safe to retry** — no request ever changes state.

- On `429`, wait for the `Retry-After` seconds (the daily counter resets at UTC midnight), then retry.
- On a `500`, retry a few times with exponential backoff (e.g. 1s, 2s, 4s). Persisting `500`s aren't your fault — [tell us](#still-stuck).
- Each request counts once against your daily limit — including **each page** of a paged read. Fetching 10,000 rows at `limit=500` is 20 requests, so budget paging against your plan.

## Still stuck?

If a request keeps failing or a number looks wrong, email **[support@equibles.com](mailto:support@equibles.com)** or [open a ticket](/tickets) — include the request URL (with the key removed) and the response you got.