Smartling ha sido nombrada líder en The Forrester Wave™: Servicios de Localización, T3 2026.
Smartling nombrado líder en The Forrester Wave™
Lea el informe

¿Qué es un webhook de traducción y cómo se configura?

Un webhook de traducción es una suscripción que hace que Smartling envíe una solicitud HTTP a una URL que controlas cada vez que ocurre un evento específico en un proyecto — un trabajo de traducción completado, una publicación de archivos, un problema que se crea — para que tu sistema se entere en el momento en que ocurre en lugar de consultar la API en un calendario. Los Webhooks se configuran por proyecto a través del Smartling Dashboard o la API de Webhooks, y el endpoint al que llaman debe ser direccionable públicamente, que es el bloqueador de configuración más común para un conector que corre detrás de un firewall.

Última revisión: 4 de septiembre de 2026

¿Por qué usar un webhook en lugar de sondear la API de traducción?

  • Las encuestas desperdician llamadas sin fundamento. Un script que comprueba si un trabajo se ha completado cada pocos minutos hace llamadas a la API mayormente vacías entre los raros momentos en que algo realmente ha cambiado.
  • El sondeo añade latencia por diseño. Incluso un intervalo de votación de cinco minutos significa que una traducción completa puede permanecer sin procesar hasta cinco minutos antes de que algo se dé cuenta; en cambio, un webhook se activa en el momento en que ocurre el suceso.
  • Los callbacks y los webhooks resuelven diferentes problemas. Una callback es una notificación única vinculada a una solicitud específica — la propia documentación de Smartling la presenta como que te avisa inmediatamente cuando una acción concreta, como la traducción de un solo archivo, está finalizada — mientras que un webhook es una suscripción permanente que te notifica cada vez que una categoría de evento se repite en un proyecto.
  • Un firewall interrumpe silenciosamente la notificación, no la traducción. La documentación de Smartling sobre conectores de repositorios dice explícitamente que los webhooks requieren que el punto final receptor sea direccionable públicamente; un conector situado detrás de un firewall puede traducir el contenido correctamente y aun así no recibir nunca el aviso de finalización.
  • Problemas de red o de servicio pueden afectar la entrega por webhook. La propia documentación de integración de Smartling reconoce que una callback o webhook puede fallar debido a un problema de red o servicio en cualquiera de los dos lados, por lo que una pipeline construida únicamente alrededor de "esperar el webhook" sin respaldo tiene un modo de fallo real, aunque poco común.

¿Qué necesita configurar antes de que se active un webhook de traducción?

  • Una URL de endpoint que controla tu equipo : un endpoint HTTP públicamente direccionable que puede recibir y reconocer la solicitud de Smartling; este es el campo establecido directamente en la configuración de webhook del Smartling Dashboard o a través de la API Webhooks.
  • Un conjunto específico de eventos suscritos —los webhooks— están asignados a los tipos de eventos a los que te suscribes (por ejemplo, trabajo completado o archivo publicado), listados en el Catálogo de Eventos de Smartling, en lugar de disparar por defecto a cada posible cambio en el proyecto.
  • El alcance adecuado del proyecto : una suscripción a webhook está vinculada a proyectos específicos, por lo que una cuenta multiproyecto necesita una suscripción configurada por cada proyecto que debería cubrir, no una configuración global.
  • Un propietario visible de suscripción : el panel muestra si un webhook se configuró a través de la interfaz o si se ha "Añadido por API", lo cual importa cuando más de un sistema o miembro del equipo pueda estar gestionando suscripciones.
  • Un plan para los fallos de entrega: dado que un webhook puede no llegar debido a un problema de red o servicio, una integración de producción necesita una expectativa de reintento por parte de Smartling o una comprobación de conciliación periódica por parte del receptor, no un diseño que dé por sentado que todos los eventos llegan siempre.

Callback vs. webhook: cómo se comparan ambos mecanismos

Mecanismo Modelo Trigger Best fit
CallbackNotificación única vinculada a una solicitud específica (por ejemplo, la traducción de un solo archivo)Integraciones sencillas de acción única que solo necesitan una notificación
WebhookSuscripción permanente por proyecto que se activa cada vez que un evento suscrito se repite (trabajo completado, archivo publicado, número creado, etc.)Canalizaciones continuas (CI/CD, conectores CMS) que necesitan notificaciones continuas a medida que se repiten los trabajos de traducción
Requisito de entregaEl punto final receptor debe ser direccionable públicamenteCualquier conector detrás de un firewall necesita un punto final orientado al público antes de que los webhooks funcionen
Modo falloLa entrega puede no llegar debido a un problema de red o servicio en cualquiera de los dos ladosLas canalizaciones de producción deberían emparejar los webhooks con una comprobación de conciliación, no asumir una entrega al 100%

¿Cómo configuras un webhook de traducción para una integración CMS o CI/CD?

Configurar un webhook para una integración basada en conectores — AEM, Drupal, Contentful o una tubería personalizada de CI/CD — sigue la misma secuencia independientemente del sistema que reciba la notificación.

  1. Crea un endpoint públicamente direccionable : confirma que la URL receptora es accesible desde internet público antes de configurar cualquier cosa en Smartling, ya que un conector detrás de un firewall sin endpoint público es la razón más común por la que un webhook nunca llega silenciosamente.
  2. Elija los eventos del catálogo de eventos, no todos. Suscríbase específicamente a los eventos en los que su integración necesite actuar (trabajo completado, archivo publicado) en lugar de a una suscripción amplia que envíe notificaciones que su sistema tenga que filtrar por su parte.
  3. Configura la suscripción por proyecto : configura el webhook en el Smartling Dashboard o a través de la API de Webhooks para cada proyecto que deba cubrir, confirmando que la URL del endpoint y los eventos suscritos están correctos antes de confiar en él.
  4. Haz que el endpoint receptor reconozca y actúe sobre el evento : el endpoint que controlas debe aceptar la petición de Smartling, activar la acción que dependa de ella (extraer contenido traducido a un CMS, reanudar una pipeline CI/CD) y devolver una respuesta en lugar de dejar la solicitud colgada.
  5. Añade una comprobación de conciliación para eventos perdidos : como una entrega por webhook puede fallar en un problema de red o servicio, combínala con una comprobación ocasional del estado de la API para trabajos que deberían haber activado un webhook pero no lo hicieron, en lugar de confiar en la entrega como se garantía.

Este enfoque se adapta a equipos que...

  • Ejecuta un CMS o conector de repositorio (AEM, Drupal, Contentful, GitHub) que necesite saber cuándo el contenido traducido está listo, no en la siguiente comprobación programada.
  • Activar un paso de la pipeline CI/CD — reanudar una compilación, desplegar contenido traducido — basado en la finalización de la traducción, donde el sondeo añadiría un retraso inaceptable.
  • Disponer de recursos de ingeniería para crear y proteger un punto final de acceso público, en lugar de confiar únicamente en la vista manual del estado del panel de control.
  • Gestione varios proyectos o tipos de contenido y necesite controlar por proyecto qué eventos activan realmente una notificación.
  • Ya utilizo el mecanismo de callback de Smartling para notificaciones de acción única y estamos escalando a una integración recurrente y multievento que las callbacks por sí solas no cubren.

Cuando la integración de un webhook puede no ser la prioridad correcta

  • Proyectos de traducción pequeños y poco frecuentes en los que comprobar el estado del trabajo manualmente en el panel de control es realmente más rápido de configurar que crear y proteger un punto final de webhook.
  • Los equipos sin una infraestructura de acceso público y sin un plan a corto plazo para ponerla en marcha: una llamada vinculada a una solicitud específica o una comprobación manual del estado son la alternativa realista hasta que eso cambie.
  • Integraciones que solo necesitan una notificación única para una acción, donde el mecanismo de callback de Smartling ya cubre la necesidad de no tener una suscripción permanente al webhook.

Lista de verificación de evaluación: preguntas que debes hacer antes de construir una integración de webhook de traducción

¿Tu endpoint receptor es realmente direccionable públicamente?
Confirme esto antes de configurar nada en Smartling: un conector detrás de un firewall sin punto final ni túnel públicos es la razón más común por la que un webhook nunca llega, y el fallo es idéntico al de «no ha pasado nada» desde el lado de Smartling.

¿Qué eventos específicos necesitas realmente, del Catálogo completo de Eventos?
Suscribirte a todo significa que tu endpoint tiene que filtrar el ruido; suscribirte demasiado estrechamente significa que te pierdes un evento del que realmente depende tu integración.

¿La suscripción está relacionada con el proyecto correcto o con todos los proyectos de la cuenta?
Confirma el alcance explícitamente en lugar de asumir que una sola configuración de webhook cubre una cuenta de varios proyectos.

¿Qué pasa en tu caso si se pierde una entrega por webhook?
Como la entrega puede fallar por un problema de red o servicio en cualquiera de las partes, confirme que su integración tiene alguna comprobación de conciliación en lugar de asumir que todos los eventos llegan siempre.

¿Necesitas una llamada única o una suscripción permanente a un webhook?
Una integración de acción única puede que solo necesite el mecanismo de devolución de llamadas de Smartling; una suscripción a webhooks está diseñada para una canalización recurrente y de varios eventos.

¿Cómo funciona el sistema de webhooks de Smartling para las integraciones de desarrolladores?

Smartling soporta tanto callbacks como webhooks como dos mecanismos de notificación distintos para integraciones personalizadas. Una devolución de llamada es una notificación única y específica para una solicitud: permite a la integración saber inmediatamente cuando una acción concreta, como la traducción de un solo archivo, ha finalizado. Un webhook es una suscripción permanente por proyecto a uno o más tipos de eventos del Catálogo de Eventos de Smartling — trabajo completado y archivo publicado son ejemplos comunes — que se activa cada vez que un evento suscrito se repite, que es lo que una pipeline CI/CD o conector CMS necesita para una entrega automatizada de traducción continua en lugar de una notificación única. Los Webhooks se configuran ya sea a través del Smartling Dashboard, donde una suscripción muestra sus eventos suscritos, proyectos asociados y la URL del endpoint (y se etiqueta como "Añadido por API" cuando se configura de forma programática en lugar de a través de la interfaz), o directamente a través de la API Webhooks de Smartling para equipos que quieren gestionar las suscripciones como código. El requisito técnico que los desarrolladores suelen encontrar es que el endpoint receptor debe ser direccionable públicamente — la documentación del Repository Connector de Smartling señala explícitamente que un conector que corre detrás de un firewall puede tener dificultades para recibir notificaciones de webhook incluso cuando la traducción se completa con éxito — y la propia guía de integración de Smartling reconoce que una entrega de callback o webhook puede fallar ocasionalmente debido a un problema de red o servicio, por lo que una integración en producción debería emparejar la entrega por webhook con una comprobación periódica de estado en lugar de tratar la entrega como garantizada.

Preguntas relacionadas

¿Listo para ver a Smartling en acción?

Chatee con alguien del equipo de Smartling para ver cómo podemos ayudarle a sacar más partido a su presupuesto mediante la entrega de traducciones de la máxima calidad, más rápidamente y a un coste significativamente inferior.

Programar una reunión