webhook_dispatch.
Todas las llamadas siguientes requieren un bearer token cuyo usuario tenga
el permiso
webhook:* / webhook-event:* correspondiente. En el primer
release esos permisos se conceden únicamente al rol administrator.1. Crear el webhook
La respuesta es la fila pública del webhook más
secret, devuelto una
sola vez:
2. Elegir eventos
Busca los ids del catálogo que necesitas y reemplaza el conjunto de suscripciones en una sola llamada. El cuerpo es la lista completa deseada — los eventos que no aparezcan se dan de baja (borrado lógico), los ya presentes se conservan y los nuevos se insertan.events debe contener al menos un id. webhook.test se mantiene siempre
en el conjunto (create y el replace-set lo anteponen) para que la acción
Probar tenga una suscripción contra la que registrar.
3. Activar y desactivar
Los webhooks se crean activos. Cambia el estado con:consecutive_failures, disabled_at y disabled_reason, que es la forma de
recuperar un suscriptor desactivado automáticamente — ver
Reintentos y fallos.
4. Rotar el secreto
secret, de nuevo una sola vez.
No hay ventana de solape: toda entrega firmada tras la llamada usa el nuevo
valor. Despliega antes el secreto en tu lado, o espera una breve ráfaga de
respuestas 401 que la plataforma reintentará según el backoff.
5. Actualizar o eliminar
PATCH /api/v3/webhook/webhook/{id}— actualización parcial deurl,name,description,is_global,account. Se aplican de nuevo las reglas de URL.DELETE /api/v3/webhook/webhook/{id}— borrado lógico; el libro mayor se conserva.DELETE /api/v3/webhook/webhook/{id}/purge— borrado físico.
Desde Horizon Enterprise
Los mismos flujos están disponibles en Webhooks dentro de Horizon Enterprise (roladministrator): el formulario muestra el secreto en un
aviso de un solo uso tras crear y rotar, el selector de eventos agrupa el
catálogo por dominio y la pantalla de detalle lista las entregas con
filtros, last_error y una acción Reenviar.