> For the complete documentation index, see [llms.txt](https://docs.toolkit.equs.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.toolkit.equs.ai/docs/api/rate-limits.md).

# Rate Limits

The default limits on API calls, request size, and the number of Issuers and Verifiers each Tenant can have, plus what happens when you hit them.

Plenty of room for real traffic, just not for runaway loops 🔁 Here's where the lines are.

The platform limits how often each caller can use the APIs, how large a single request can be, and how many Issuers and Verifiers a Tenant can own. The values on this page are the defaults. If they don't fit your use case, contact EQUS.

### Request rates ⏱️

Each API counts requests separately for every authenticated caller. For your back end, the caller is your Tenant's client, identified by the access token you get with your client credentials (see [Authentication](/docs/api/authentication.md)). For the wallet APIs, it's the signed-in Holder or agent.

Both limits apply at the same time:

| Window     | Requests per caller |
| ---------- | ------------------- |
| 10 seconds | 100                 |
| 1 hour     | 10,000              |

#### When you reach a limit 🛑

The API answers `429 Too Many Requests` with the error code `TOO_MANY_REQUESTS`. Responses carry the standard `RateLimit-*` headers, which show how much of the allowance is left and when it resets.

Wait for the reset before retrying, and back off rather than retrying in a tight loop: retries count against the same allowance.

### Request size 📦

The same limits apply to every request body, on all the platform APIs:

| Limit                                               | Default           |
| --------------------------------------------------- | ----------------- |
| Body size, JSON or URL-encoded                      | 100 KB            |
| Nesting depth of objects and arrays                 | 12 levels         |
| Length of an object key                             | 64 characters     |
| Length of a string value                            | 65,536 characters |
| Keys and array items, counted across the whole body | 4,096             |

A body over the size limit is refused with `413 Payload Too Large`. A body that breaks one of the other limits is refused with `400 Bad Request` and an error code naming the limit: `depth_exceeded`, `key_size_exceeded`, `string_too_large`, `number_too_large` or `too_many_key_pairs`.

### Tenant resources 🏢

Every [Issuer](/docs/issuance/configuration-issuer-and-vc-schema.md) and every [Verifier](/docs/presentation/configuration.md) gets its own signing key in the platform's KMS, so the number of each a Tenant can own is capped. The Issuer and Verifier limits are therefore also your limit on signing keys.

| Resource  | Limit per Tenant |
| --------- | ---------------- |
| Issuers   | 50               |
| Verifiers | 50               |

* **Deactivated ones still count.** Issuers and Verifiers can't be deleted, because they keep their keys so the credentials and requests they signed stay verifiable.
* **Reaching the limit** returns `409 Conflict` with the error code `tenant_resource_limit_reached`, naming the resource and the limit.
* **Raising the limit** is something EQUS does for your Tenant on request. You can't change it yourself.

VC Schemas and VP Schemas aren't capped.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.toolkit.equs.ai/docs/api/rate-limits.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.