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

# Límites de uso

> Cuántas requests podés hacer, cómo leer los headers y cómo reintentar.

Para que una app no degrade la tienda de un comerciante, limitamos cuántas requests puede hacer. El límite se calcula por la combinación **app × comercio**: tu app tiene un cupo propio en cada tienda donde está instalada, y el uso en una tienda no afecta a las demás.

## Cómo funciona

Usamos un cubo que se vacía de a poco (*leaky bucket*): cada request llena el cubo una unidad, y el cubo se vacía a un ritmo constante. Mientras no se desborde, podés hacer ráfagas.

| Plan del comercio | Capacidad | Goteo |
| - | - | - |
| Professional | capacidad de **40** requests | **2 requests por segundo** |
| Enterprise | ×5: capacidad de 200 requests | ×5: 10 requests por segundo |
| Tiendas demo, tu propia tienda de desarrollo | ×1: igual que Professional | ×1 |

En la práctica, en una tienda Professional podés hacer una ráfaga de 40 requests y después sostener 2 por segundo.

## Headers

Las respuestas a requests autenticados (incluidos los errores de la API) traen:

| Header | Significado |
| - | - |
| `X-RateLimit-Limit` | Capacidad total de tu cubo. |
| `X-RateLimit-Remaining` | Requests que te quedan antes de desbordar el cubo. |
| `X-RateLimit-Reset` | Segundos hasta que el cubo se vacíe por completo. |

Cuando te pasás, la respuesta es `429 rate_limited` e incluye además `Retry-After`, con los segundos que tenés que esperar antes de reintentar:

```http theme={null}
HTTP/1.1 429 Too Many Requests
X-RateLimit-Limit: 40
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 20
Retry-After: 1
Content-Type: application/json

{"error":{"code":"rate_limited","message":"Superaste el límite de requests de esta app para esta tienda","details":[],"request_id":"..."}}
```

Los endpoints de OAuth tienen sus propios límites (ver [Autenticación OAuth](/oauth#errores-del-endpoint-de-token)).

## Recomendaciones

* **Respetá `Retry-After`.** Es el tiempo mínimo antes de que haya lugar de nuevo.
* **Reintentá con backoff exponencial** (1 s, 2 s, 4 s...) y algo de variación aleatoria, para que varios workers no reintenten todos a la vez.
* **Mirá `X-RateLimit-Remaining`** y frená antes de llegar a cero, en lugar de esperar al `429`.
* **No hagas polling.** Para enterarte de cambios, suscribite a [webhooks](/webhooks) y, para la sincronización de respaldo, pedí sólo lo nuevo con `updated_since` en lugar de recorrer todo el catálogo.
* **Paginá con `limit` alto** (hasta 100) en vez de muchas páginas chicas.

<Warning>
  El polling agresivo es causal de rechazo en la revisión de tu app (ver [Revisión y publicación](/revision)). En la homologación te pedimos un diagrama de secuencia de cómo consultás la API.
</Warning>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.