<!-- Canonical URL: https://ask.atlascloud.ai/es/how-often-poll-asynchronous-video-generation-api -->

# ¿Con qué frecuencia debes consultar una API asíncrona de generación de video?

> Consulta con rapidez solo durante el breve periodo en que el trabajo puede cambiar pronto; después aplica espera progresiva con jitter y un límite. Prefiere webhooks fiables, respeta las señales de rate limit y detén las consultas de trabajos terminales o abandonados.

<!-- Canonical URL: https://ask.atlascloud.ai/how-often-poll-asynchronous-video-generation-api -->

Un bucle de polling debe responder al tiempo de finalización, al coste de las solicitudes y a la incertidumbre, no a un `sleep` fijo. Cinco segundos pueden funcionar para una vista previa y ser un desperdicio para un render de varios minutos.

Empieza por la recomendación del proveedor. Si no existe, usa una demora moderada, auméntala tras respuestas sin cambios, añade jitter y limita tanto los intentos como la edad total.

## Parte de la duración prevista del trabajo

Guarda percentiles reales por modelo, duración, resolución y estado de cola. No conviertas unas pocas ejecuciones en un SLA inventado.

| Duración prevista | Intervalo inicial | Intervalo posterior | Uso típico |
|---|---:|---:|---|
| Menos de 30 segundos | 2 a 4 segundos | 5 a 8 segundos | Vista previa |
| 30 a 120 segundos | 4 a 8 segundos | 10 a 20 segundos | Generación estándar |
| 2 a 10 minutos | 10 a 20 segundos | 30 a 60 segundos | Render largo |
| Desconocida | 5 segundos | Backoff hasta 60 segundos | Modelo nuevo |

Son puntos de partida, no promesas del proveedor.

## Usa backoff adaptativo

```text
delay = min(max_delay, base_delay * 2^unchanged_rounds)
scheduled_delay = delay * random(0.8, 1.2)
```

Reinicia `unchanged_rounds` cuando haya progreso real. Mantén la demora máxima por debajo de la latencia de detección que acepta el producto.

## Trata las señales del proveedor como autoridad

| Señal | Acción segura |
|---|---|
| `Retry-After` | Esperar al menos ese tiempo |
| Rate limit | Aplicar backoff global a la ruta |
| En cola | Consultar lentamente |
| Procesando con progreso | Programar cerca del tiempo restante |
| Éxito o fallo | Detener polling normal |
| Trabajo desconocido | Reconciliar antes de reenviar |

El adaptador debe interpretar el schema exacto de cada modelo.

## Combina webhooks y reconciliación

Valida firmas, guarda IDs de evento, deduplica y responde rápido. Conserva un ciclo lento para trabajos sin webhook y escala los que superen la edad máxima.

## Limita la concurrencia de toda la cuenta

Usa un presupuesto global o por proveedor. Prioriza trabajos vencidos, interactivos y cercanos a su finalización, y separa capacidad de status de capacidad de envío.

## Deja de consultar trabajos terminales

Detente en éxito, fallo, cancelación, abandono o fin de reconciliación. Un estado local `timed_out` significa que dejaste de esperar, no que el proveedor falló. Conserva el ID remoto.

## Mide la eficiencia

Registra solicitudes por trabajo terminado, retraso de detección, rate limits, edad de trabajos sin resolver, cobertura de webhooks y backlog.

[Atlas Cloud](https://www.atlascloud.ai/?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=how-often-poll-asynchronous-video-generation-api) puede consolidar modelos de texto, imagen y video en una plataforma compatible con OpenAI. Aun así, guarda la ruta exacta y aplica reglas específicas.

## En resumen

Usa guía del proveedor, backoff adaptativo, jitter, límites de concurrencia y una política de parada. Los webhooks notifican y el polling lento reconcilia.

## FAQ

### ¿Cuál es un intervalo inicial razonable?

Sigue la recomendación documentada. Si no existe, entre 3 y 5 segundos es un punto de partida prudente para trabajos cortos, seguido de backoff adaptativo.

### ¿Todos los trabajos deben usar el mismo intervalo?

No. Usa duración prevista, edad de cola, estado y guía del proveedor. Un render largo debe consultarse con menos frecuencia que una vista previa.

### ¿Un error HTTP debe detener las consultas?

No siempre. Reintenta fallos transitorios y rate limits con backoff, pero detente ante errores claros de autenticación, validación, not-found o estados terminales.

### ¿Los webhooks siempre son mejores?

Reducen solicitudes, pero pueden retrasarse o duplicarse. Valídalos y deduplícalos, y conserva una reconciliación lenta.

### ¿Cómo evito un thundering herd?

Añade jitter, limita consultas concurrentes y programa cada trabajo de forma independiente.

### ¿Puede Atlas Cloud simplificar el polling multimodelo?

Puede consolidar acceso a modelos de texto, imagen y video, mientras la aplicación normaliza estados y tiempos de cada modelo.
