Skip to main content

Webhooks

Los webhooks de Tupana te permiten recibir notificaciones en tiempo real cuando ocurren eventos importantes en tu sistema de facturación. Esta guía te ayudará a configurar y usar webhooks de forma efectiva.

¿Qué son los webhooks?

Los webhooks son una forma de comunicación donde Tupana envía automáticamente una notificación HTTP POST a una URL que tú configures cuando ocurre un evento específico (por ejemplo, cuando se emite una factura). A diferencia de las APIs donde tú haces las consultas, con los webhooks Tupana te notifica cuando algo importante sucede, permitiéndote mantener tu sistema sincronizado en tiempo real.

Cómo crear un webhook

Desde la interfaz web

  1. Ve a Configuración → Webhooks
  2. Haz clic en Nuevo Webhook
  3. Completa los siguientes campos:
    • URL del Endpoint: La URL de tu servidor que recibirá las notificaciones (debe ser HTTPS)
    • Eventos: Selecciona los eventos que quieres recibir
    • Secret (opcional): Una clave secreta para verificar la autenticidad de las notificaciones
    • Activo: Marca esta opción para activar el webhook
  4. Haz clic en Guardar

Ejemplo de configuración

Seguridad

Firma de webhooks

Para verificar que las notificaciones provienen realmente de Tupana, puedes configurar un secret al crear el webhook. Tupana firmará cada notificación usando HMAC SHA-256.

Cómo verificar la firma

Node.js:
Python:

Headers enviados

Cada notificación incluye los siguientes headers:
  • Content-Type: application/json
  • User-Agent: Pana-Webhook/1.0
  • X-Pana-Event-Id: ID único del evento (UUID)
  • X-Pana-Event-Type: Tipo de evento (ej: document.issued)
  • X-Pana-Timestamp: Timestamp ISO 8601 del evento
  • X-Pana-Delivery: ID único del intento de entrega (UUID)
  • X-Pana-Signature: Firma HMAC SHA-256 (si configuraste un secret)

Eventos soportados

Eventos de documentos

  • document.issued: Se emitió un documento exitosamente
  • document.issue_failed: Falló la emisión de un documento
  • document.updated: Se actualizó un documento existente
  • document.delivered: Se entregó un documento (PDF/XML enviado al cliente)
  • document.rejected: El SII rechazó el documento
  • document.paid: El documento fue pagado (conciliación bancaria)
  • document.unpaid: El documento volvió de pagado a no pagado (se revirtió el pago/conciliación)
  • document.cancelled: El documento fue anulado o tiene nota de crédito

Eventos de documentos programados

  • scheduled_document.created: Se creó un documento programado
  • scheduled_document.updated: Se actualizó un documento programado
  • scheduled_document.run_started: Se inició la ejecución de un documento programado
  • scheduled_document.run_succeeded: La ejecución de un documento programado fue exitosa
  • scheduled_document.run_failed: La ejecución de un documento programado falló

Eventos de credenciales

  • credential.validated: Una credencial SII fue validada exitosamente contra el SII
  • credential.invalid: Una credencial SII quedó inválida (clave incorrecta o cuenta bloqueada)

Eventos operacionales

  • webhook.test: Evento de prueba para verificar que tu endpoint funciona correctamente

Payloads por Evento

Cada evento tiene una estructura de payload específica. Navega a cada evento para ver su payload completo:

Eventos de Documentos

document.issued

Se dispara cuando un documento se emite exitosamente. Incluye el PDF y XML del documento.
Campos específicos:
  • pdf_file: URL del PDF del documento (solo en este evento)
  • xml_file: URL del XML del documento
  • document_issuer: Información completa del emisor
  • document_receiver: Información completa del receptor
  • details: Array con todas las líneas del documento

document.issue_failed

Se dispara cuando falla la emisión de un documento.
Nota: En este evento, folio, pdf_file y xml_file pueden ser null ya que el documento no se emitió exitosamente.

document.updated

Se dispara cuando se actualiza un documento existente.
Nota: pdf_file puede ser null en este evento ya que solo se genera en la emisión inicial.

document.delivered

Se dispara cuando se entrega un documento (PDF/XML enviado al cliente).

document.rejected

Se dispara cuando el SII rechaza un documento.

document.paid

Se dispara cuando un documento es pagado (conciliación bancaria).

document.unpaid

Se dispara cuando un documento que estaba pagado vuelve a no pagado, es decir, cuando se revierte el pago o la conciliación (manualmente o porque una nota de crédito / recálculo de saldo dejó la factura con saldo pendiente). El payload es idéntico al de document.paid; solo cambia el campo event.

document.cancelled

Se dispara cuando un documento es anulado o tiene una nota de crédito asociada.
Nota: El campo references puede contener información sobre la nota de crédito o anulación asociada.

Eventos de Documentos Programados

scheduled_document.created

Se dispara cuando se crea un documento programado.
Campos específicos:
  • frequency: Frecuencia de ejecución (daily, weekly, monthly, etc.)
  • status: Estado del documento programado (active, paused, etc.)
  • next_execution: Fecha y hora de la próxima ejecución

scheduled_document.updated

Se dispara cuando se actualiza un documento programado.

scheduled_document.run_started

Se dispara cuando se inicia la ejecución de un documento programado.

scheduled_document.run_succeeded

Se dispara cuando la ejecución de un documento programado es exitosa.
Nota: next_execution se actualiza con la próxima fecha de ejecución.

scheduled_document.run_failed

Se dispara cuando falla la ejecución de un documento programado.

Eventos de Credenciales

Estos eventos se disparan por credencial individual, incluyendo las creadas vía creación de credenciales en lote. El webhook se configura por master_entity, y una credencial puede estar asociada a más de una entidad: si eso ocurre, se envía una notificación por cada entidad que tenga un webhook suscrito al evento.

credential.validated

Se dispara cuando una credencial SII fue validada exitosamente contra el SII (login exitoso).

credential.invalid

Se dispara cuando una credencial SII queda inválida: clave incorrecta o cuenta bloqueada.
Nota: status refleja el estado de la credencial en Tupana (VALID / INVALID), no un detalle del error. El payload no distingue si la causa fue una clave incorrecta o una cuenta bloqueada.

Eventos Operacionales

webhook.test

Evento de prueba para verificar que tu endpoint funciona correctamente.
Uso: Este evento se puede disparar manualmente desde la interfaz para probar tu endpoint sin esperar un evento real.

Estructura común del payload

Todos los payloads comparten esta estructura base:
  • event: Tipo de evento que disparó el webhook (string)
  • created_at: Timestamp ISO 8601 del evento (string)
  • data: Objeto con los datos específicos del evento (varía según el tipo)

Campos comunes en eventos de documentos

  • id: ID único del documento en Tupana (integer)
  • folio: Folio del documento (string o null)
  • date_issued: Fecha de emisión en formato ISO (string)
  • amount_with_iva: Monto total con IVA (float)
  • is_sandbox: Indica si es un documento de prueba (boolean)
  • dte_type: Tipo de documento tributario (objeto con code y description)
  • sender: Información del emisor (objeto con id, name, tax_id, email)
  • receiver: Información del receptor (objeto con id, name, tax_id, email o null)
  • document_total: Totales del documento (objeto con net_amount, iva_rate, iva_amount, total_amount)
  • details: Array con las líneas del documento
  • xml_file: URL del XML del documento (string o null)
  • pdf_file: URL del PDF del documento (string o null, solo en document.issued)

Reintentos

Tupana reintenta automáticamente las entregas fallidas usando una estrategia exponencial:
  1. Intento 1: Inmediato
  2. Intento 2: 1 minuto después
  3. Intento 3: 5 minutos después
  4. Intento 4: 15 minutos después
  5. Intento 5: 1 hora después
  6. Intento 6: 6 horas después
Máximo de reintentos: 5 por defecto (configurable por webhook)

Idempotencia

Cada notificación tiene un delivery_id único (UUID). Si recibes el mismo delivery_id múltiples veces, es un reintento del mismo evento. Tu endpoint debe ser idempotente para evitar procesar el mismo evento varias veces.

Recomendaciones

  • Responde con código 2xx (200-299) para indicar éxito
  • Responde rápidamente (idealmente < 2 segundos)
  • Si tu endpoint tarda más, responde 202 Accepted y procesa asíncronamente
  • No proceses la misma notificación dos veces (usa delivery_id para deduplicar)

Errores comunes

Error 4xx (Client Error)

Si tu endpoint responde con un código 4xx (400-499), Tupana asume que hay un problema con la configuración o el formato de la notificación. Estos errores se reintentan, pero si persisten, considera:
  • Verificar que la URL es correcta y accesible
  • Verificar que tu endpoint acepta POST requests
  • Verificar que tu endpoint acepta Content-Type: application/json
  • Revisar los logs de tu servidor para ver el error específico

Error 5xx (Server Error)

Si tu endpoint responde con un código 5xx (500-599), Tupana asume que hay un problema temporal en tu servidor. Estos errores se reintentan automáticamente.

Timeout

Si tu endpoint no responde en 120 segundos, Tupana considera la entrega como fallida y la reintenta.

Monitoreo y Debug

Dashboard de métricas

En Configuración → Webhooks, puedes ver:
  • Total de entregas: Número total de notificaciones enviadas
  • Tasa de éxito: Porcentaje de entregas exitosas
  • Fallos: Número de entregas fallidas
  • Reintentos: Número de reintentos necesarios
  • Tiempo promedio de respuesta: Tiempo que tarda tu endpoint en responder
  • Top 5 errores: Los errores más comunes
  • Top 5 endpoints con fallos: URLs que más fallan

Historial de entregas

Puedes ver el historial completo de cada intento de entrega, incluyendo:
  • Status code recibido
  • Tiempo de respuesta
  • Mensaje de error (si falló)
  • Payload completo enviado

Mejores prácticas

  1. Usa HTTPS: Tu endpoint debe usar HTTPS para seguridad
  2. Configura un secret: Siempre configura un secret y verifica la firma
  3. Sé idempotente: Usa delivery_id para evitar procesar el mismo evento dos veces
  4. Responde rápido: Responde en menos de 2 segundos o usa 202 Accepted
  5. Maneja errores: Responde con códigos HTTP apropiados
  6. Monitorea métricas: Revisa regularmente el dashboard de métricas
  7. Prueba primero: Usa el evento webhook.test para verificar tu endpoint

Ejemplo completo

Endpoint de ejemplo (Node.js + Express)

Soporte

Si tienes problemas con tus webhooks:
  1. Revisa el Dashboard de Métricas en Configuración → Webhooks
  2. Revisa el Historial de Entregas para ver errores específicos
  3. Contacta a soporte con el delivery_id del intento fallido