DeepScript
Pregunta

¿Debo usar webhooks o polling para una API de transcripción?

Respuesta corta

Webhooks para la entrega principal, polling como respaldo – la configuración de producción más robusta. El polling solo malgasta peticiones; los webhooks solos arriesgan eventos perdidos.

Los jobs de transcripción suelen ser asíncronos: subes un archivo, la API devuelve un `transcription.id`, y el resultado llega más tarde. ¿Cómo te enteras de que está listo?

Polling Tu código pregunta a la API periódicamente: « ¿El job X ha terminado? \" Típicamente: GET `/v1/transcriptions/{id}/status` cada 2-5 segundos. Cuando el estado cambia a `completed`, recuperas el resultado.

Ventajas: simple, no se necesita URL pública, funciona tras cortafuegos y dentro de jobs en segundo plano. Inconvenientes: muchas peticiones vacías (un archivo de 1 h procesado en 2 min cuesta 60-100 sondeos), riesgo de límite de tasa, latencia máx. = intervalo de polling.

Webhooks Registras una URL; la API la llama cuando el job termina. POST con un cuerpo como `{ "event": "transcription.completed", "id": "…", "result": { … } }`. Firmado con HMAC-SHA256 para que puedas verificar que es realmente el proveedor.

Ventajas: ninguna petición vacía, latencia inferior al segundo, escala a millones de jobs. Inconvenientes: necesita una URL pública (o un túnel como ngrok en dev), debes implementar tú los reintentos, la idempotencia y la verificación de firma. Si la entrega del webhook falla (servidor caído, fallo de red), el evento puede perderse.

La respuesta correcta: ambos Los sistemas en producción combinan los dos. Webhooks para la entrega principal – rápido, eficiente. Polling como red de seguridad cada 5-10 minutos para los jobs encolados desde hace más de 30 min – capta los casos en que el webhook se perdió.

Patrón concreto ``` // Al subir const job = await api.transcribe({ file, webhook_url: "https://…" }) await db.insert({ id: job.id, status: "queued" })

// Endpoint del webhook app.post("/webhook", (req) => { if (!verifySignature(req)) return 401 await db.update(req.body.id, { status: "completed", result: req.body.result }) })

// Job de respaldo (cron, cada 10 min) const stuck = await db.where("status", "queued").and("createdAt", "<", now-30min) for (const j of stuck) { const fresh = await api.getStatus(j.id) if (fresh.status === "completed") await db.update(j.id, fresh) } ```

Especificidades de DeepScript Admitimos ambos: registra webhooks vía `POST /v1/webhooks` (eventos: `transcription.completed`, `transcription.failed`, `balance.low`), haz polling vía `GET /v1/transcriptions/{id}/status`. Para una interfaz en tiempo real en el navegador, también exponemos SSE (`GET /v1/transcriptions/{id}/events`) – los server-sent events transmiten actualizaciones de estado directamente al cliente sin abrir un canal WebSocket.

Preguntas relacionadas

¿Te queda alguna pregunta?

Tres transcripciones gratis para probar. O escríbenos un correo – respondemos en menos de 24 horas, también a preguntas de cumplimiento.

¿Webhooks o polling para la transcripción? Comparación pragmática | DeepScript