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

# Límites de tasa

> Límites de tasa de la API de Enrow por clave de API, la respuesta 429 y cómo gestionar la limitación con backoff y endpoints masivos

La API de Enrow aplica límites de tasa para garantizar un uso justo y mantener la calidad del servicio. El límite es el mismo en todos los endpoints y todos los planes, se aplica **por clave de API** y se mide en **solicitudes por segundo (RPS)**. Esta página explica los límites predeterminados, qué ocurre cuando los superas y cómo mantenerte dentro de la cuota al escalar.

## ¿Cuáles son los límites de tasa predeterminados?

Cada endpoint POST permite **10 solicitudes por segundo** por clave de API. El límite es idéntico en todos los endpoints y todos los planes:

| Endpoint                    | Límite de tasa |
| --------------------------- | -------------- |
| `POST /email/find/single`   | 10 req/s       |
| `POST /email/find/bulk`     | 10 req/s       |
| `POST /email/verify/single` | 10 req/s       |
| `POST /email/verify/bulk`   | 10 req/s       |
| `POST /phone/single`        | 10 req/s       |
| `POST /phone/bulk`          | 10 req/s       |

Los endpoints GET no tienen límite de tasa, por lo que recuperar resultados — por ejemplo el [resultado de un solo email](/es/api-reference/email-finder/get-single-result) o los [resultados masivos](/es/api-reference/email-finder/get-bulk-results) — no cuenta para tu cuota.

<Note>
  Los límites de tasa son **por clave de API** y se miden en **solicitudes por segundo** (RPS). Cada [clave de API](/es/authentication) tiene su propia cuota independiente.
</Note>

## ¿Qué ocurre cuando supero el límite de tasa?

Cuando superas el límite de tasa, la API devuelve una respuesta `429 Too Many Requests`:

```json theme={null}
{
  "message": "Too Many Requests"
}
```

La forma recomendada de gestionar un `429` es implementar un backoff exponencial — esperar un retardo progresivamente mayor antes de cada reintento para que la clave de API tenga tiempo de volver por debajo del límite:

```javascript theme={null}
async function requestWithRetry(url, options, maxRetries = 3) {
  for (let attempt = 0; attempt < maxRetries; attempt++) {
    const response = await fetch(url, options);

    if (response.status === 429) {
      const delay = Math.pow(2, attempt) * 1000;
      await new Promise(resolve => setTimeout(resolve, delay));
      continue;
    }

    return response;
  }

  throw new Error('Max retries exceeded');
}
```

Para ver la lista completa de códigos de respuesta y cómo gestionarlos, consulta [Códigos de estado](/es/status-codes) y [Gestión de errores](/es/error-handling).

## ¿Cómo puedo evitar alcanzar el límite de tasa?

La forma más eficaz de mantenerte dentro de la cuota es enviar menos solicitudes pero más grandes y recibir los resultados mediante webhooks en lugar de sondeo.

<AccordionGroup>
  <Accordion title="Usa endpoints masivos">
    En lugar de realizar 100 solicitudes individuales, realiza 1 solicitud masiva (hasta 5.000 elementos para email, 3.000 para teléfono). Un único POST masivo cuenta como 1 solicitud frente a tu límite de tasa.

    ```javascript theme={null}
    // ❌ 100 requests = 10 seconds at 10 RPS
    for (const contact of contacts) {
      await findEmail(contact);
    }

    // ✅ 1 request
    await findEmailsBulk(contacts);
    ```

    Consulta [Buscar emails](/es/api-reference/email-finder/find-bulk) y [Verificar emails](/es/api-reference/email-verifier/verify-bulk) para empezar.
  </Accordion>

  <Accordion title="Usa webhooks en lugar de sondeo">
    Sondear el endpoint GET desperdicia tu cuota de límite de tasa. Usa [webhooks](/es/how-webhooks-work) para recibir los resultados automáticamente en cuanto se completa una búsqueda o verificación.
  </Accordion>

  <Accordion title="Almacena los resultados en caché">
    Guarda los resultados para evitar llamadas redundantes a la API para el mismo contacto, lo que además ahorra [créditos](/es/credits-billing).
  </Accordion>
</AccordionGroup>

## ¿Puedo obtener límites de tasa más altos?

Sí. Enrow puede aumentar tu RPS caso por caso. Contáctanos en [api@enrow.io](mailto:api@enrow.io) indicando tu caso de uso y el volumen previsto.

## FAQ

<AccordionGroup>
  <Accordion title="¿Se comparten los límites de tasa entre endpoints?">
    No. El límite de 10 req/s se aplica de forma independiente a cada endpoint POST, y la cuota se rastrea **por clave de API** en lugar de por cuenta.
  </Accordion>

  <Accordion title="¿Las solicitudes GET cuentan para el límite de tasa?">
    No. Los endpoints GET no tienen límite de tasa, por lo que sondear resultados no consume tu cuota de RPS. Dicho esto, los webhooks siguen siendo preferibles al sondeo frecuente.
  </Accordion>

  <Accordion title="¿Una solicitud masiva cuenta como una sola solicitud?">
    Sí. Un único POST masivo cuenta como 1 solicitud frente a tu límite de tasa, aunque puede contener hasta 5.000 elementos para email o 3.000 para teléfono.
  </Accordion>

  <Accordion title="¿Qué código de estado señala un error de límite de tasa?">
    Una respuesta `429 Too Many Requests` con el cuerpo `{ "message": "Too Many Requests" }`. Reintenta con backoff exponencial. Consulta [Gestión de errores](/es/error-handling) para más detalles.
  </Accordion>
</AccordionGroup>

## Próximos pasos

<CardGroup cols={2}>
  <Card title="Buscar emails en masa" icon="layer-group" href="/es/api-reference/email-finder/find-bulk">
    Ejecuta hasta 5.000 búsquedas de email en una sola solicitud para ahorrar cuota de límite de tasa.
  </Card>

  <Card title="Webhooks" icon="bell" href="/es/how-webhooks-work">
    Recibe los resultados automáticamente en lugar de sondear los endpoints GET.
  </Card>

  <Card title="Gestión de errores" icon="triangle-exclamation" href="/es/error-handling">
    Gestiona el código 429 y otras respuestas de forma elegante en tu integración.
  </Card>

  <Card title="Créditos y facturación" icon="coins" href="/es/credits-billing">
    Consulta cómo se consumen los créditos en cada endpoint.
  </Card>
</CardGroup>