Catálogo de eventos

Esta página describe cada evento que Axis Pro puede enviar por webhook. Cómo
suscribirse, verificar la firma y manejar reintentos está en
Recibir eventos por webhook.

Todos los eventos avisan; ninguno trae el dato completo. El cuerpo lleva
identificadores y estado, nunca datos del huésped, montos ni fechas. Para el
detalle, se pide data.url con la propia API key: siempre devuelve el estado
actual, aunque el evento haya llegado tarde.

Resumen

El alcance aplica al crear la suscripción por la API y a cualquier cambio
posterior sobre ella. Desde el panel del hotel no hace falta ningún alcance.
GET /webhooks/events devuelve esta misma lista, con una descripción corta de
cada evento.

El sobre común

Todos los eventos comparten el mismo sobre; sólo cambia data:

{
  "id": "0b5f8c1e-1111-4222-8333-444455556666",
  "type": "booking.created",
  "api_version": "v1",
  "created_at": "2026-09-28T15:04:05Z",
  "tenant": "…",
  "data": { }
}

id identifica al evento y sirve para descartar duplicados. created_at
está en UTC. tenant identifica la cuenta del hotel.

Reservas

Todos los eventos de reserva traen este data:

{
  "object": "booking",
  "id": "01a06051-c523-7396-a1b7-273f29c9f7e3",
  "property_id": "01a06051-c4e9-7011-a5f2-3d4c5b6a7980",
  "code": "P8582-000001",
  "status": "confirmed",
  "url": "https://api.axispro.travel/api/external/v1/bookings/01a06051-c523-7396-a1b7-273f29c9f7e3"
}

Algunos agregan un campo, indicado en cada evento.

booking.created

Se creó una reserva, por cualquier canal: el equipo del hotel, una OTA, el
sitio web o esta API.

• Una reserva del sitio web que todavía no se pagó llega con
  status: "pending". Cuando se paga, llegan booking.confirmed y
  booking.payment_registered.
• Una reserva de varias habitaciones produce un booking.created por cada
  habitación.

booking.updated

Se editó una reserva. Trae changes, una lista que dice qué cambió, nunca
los valores:

changes nunca viene vacía. Una edición que mueve fechas y cambia el precio
llega como "changes": ["dates", "price"]. Una modificación que llega de una
OTA dice dates o unit cuando cambian; si sólo cambió el precio, llega como
other.

booking.status_changed

La reserva pasó de un estado a otro. Trae previous_status:

{ "status": "checked_in", "previous_status": "confirmed" }

Llega en toda transición. Las cuatro que un integrador suele querer por
separado — confirmar, llegar, salir, cancelar — llegan además como su propio
evento, así que no hace falta filtrar booking.status_changed: basta con
suscribirse al específico.

booking.confirmed

La reserva quedó confirmada. Trae previous_status. Pasa cuando:

• se paga en el sitio web una reserva pendiente (previous_status: "pending");
• el hotel confirma a mano una reserva pendiente;
• se reactiva una reserva cancelada (previous_status: "cancelled").

Siempre llega junto con booking.status_changed.

booking.checked_in

El huésped hizo check-in. Trae previous_status. Siempre llega junto con
booking.status_changed.

booking.checked_out

El huésped hizo check-out. Trae previous_status. Llega junto con
booking.status_changed y, poco después, con un
unit.dirty de la habitación que dejó.

booking.cancelled

La reserva se canceló. Trae previous_status. Siempre llega junto con
booking.status_changed. Si el hotel devuelve dinero, el reembolso llega
después como booking.refunded.

booking.deleted

La reserva se borró. Mientras siga borrada, su data.url responde
404 BOOKING_NOT_FOUND — ese 404 es la confirmación, no un error.

booking.restored

Se recuperó una reserva borrada. Su data.url vuelve a responder.

booking.guest_changed

Cambió el titular de la reserva — el huésped que devuelve guest en
GET /bookings/{booking} — o se editaron sus datos desde la reserva:

• el hotel asignó a otro huésped como titular;
• en una reserva de grupo, la lista de ocupantes reasignó el titular de una
  habitación;
• el huésped corrigió sus datos durante el check-in digital.

No llega por los acompañantes, porque esta API no los expone. Tampoco llega
cuando se edita la ficha del huésped desde el módulo de huéspedes, porque eso
afecta a todas sus reservas a la vez.

Dinero

Los eventos de dinero traen transaction_id y nunca el monto. Para
saber cuánto se pagó o cuánto falta, se leen paid_amount y balance_due de
la reserva:

{ "status": "confirmed", "transaction_id": "01a0b1c2-d3e4-7f50-8a9b-0c1d2e3f4a5b" }

Los pagos a la cuenta de un grupo no cambian el saldo de cada reserva y no
producen estos eventos.

booking.payment_registered

Se registró un pago de la reserva: en recepción, con un link de pago o en el
sitio web. Si la reserva estaba pendiente, el pago la confirma, y llegan
tres eventos: booking.status_changed, booking.confirmed y
booking.payment_registered.

booking.payment_reverted

Se revirtió un pago de la reserva. Puede llegar para una reserva ya borrada; en
ese caso su data.url responde 404.

booking.refunded

Se registró un reembolso de una reserva cancelada.

Habitaciones

Los eventos de habitación son para cerraduras, mensajería de check-in
anticipado y herramientas de limpieza. Su data es distinto:

{
  "object": "unit",
  "id": "01a06051-69f2-724a-bfe0-57b5b5dab318",
  "property_id": "01a06051-c4e9-7011-a5f2-3d4c5b6a7980",
  "inventory": { "id": "01a06051-7a10-7c1d-9e2f-3a4b5c6d7e8f", "label": "204" },
  "state": "clean",
  "ready": true,
  "url": "https://api.axispro.travel/api/external/v1/units/01a06051-69f2-724a-bfe0-57b5b5dab318/housekeeping"
}

• id es la unidad; en un Room Type, inventory nombra la habitación física
  (label es su número o nombre). En una unidad de una sola habitación,
  inventory es null.
• state es dirty, clean o inspected, y ready dice si ya se puede
  entregar.
• data.url lleva a GET /units/{unit}/housekeeping, que funciona aunque el
  hotel no venda esa habitación por esta API.

Más detalle en
Estado de las habitaciones.

unit.ready

La habitación quedó lista para el siguiente huésped:

• en un hotel que no exige inspección, cuando queda limpia;
• en un hotel que sí la exige, cuando un supervisor la marca como
  inspeccionada — no antes.

Sólo avisa cuando la habitación entra en lista. Si deja de estarlo sin
ensuciarse, por ejemplo porque el hotel empieza a exigir inspección, no llega
evento.

unit.dirty

La habitación quedó sucia. Lo normal es que sea por un check-out, que
ensucia la habitación sin que nadie la marque; también pasa si una inspección
la rechaza o si el equipo la marca a mano.

Flujos completos

Los eventos no llegan en orden garantizado, ni siquiera los de un mismo
flujo. Hay que tratarlos como avisos independientes y releer data.url ante
cualquiera.

Relacionado

• Recibir eventos por webhook
• Alcances y el header X-Property
• Reservas
• Housekeeping