API REST para el motor de reservas de tu camping: envío automático de partes de viajeros

El problema: entrar los datos de cada reserva online a mano

Si tu camping recibe reservas desde una web propia, un motor de reservas o una OTA, ya conoces la rutina: la reserva llega al sistema, abres el panel de AutoSES, la introduces a mano y envías el parte. Funciona, pero escala mal. Con cinco o diez reservas diarias en temporada alta, la entrada manual se convierte en un trabajo mecánico que resta tiempo a la atención al campista.

Además, hay margen de error: un dato copiado mal, una fecha invertida, un email del titular equivocado que impide que el campista reciba el enlace de check-in. El problema no es el parte de viajeros en sí, sino la brecha entre tu motor de reservas y la plataforma de partes.

La solución: API REST que crea la reserva y notifica a SES en una llamada

La API REST v1 de AutoSES cierra esa brecha. Tu motor de reservas llama a un endpoint, y la plataforma hace el resto:

• Registra la reserva vinculada a tu cuenta de propietario.
• Envía la notificación de llegada a SES.hospedajes del Ministerio del Interior.
• Devuelve la checkin_url: el enlace que el campista necesita para completar su parte de viajeros.

Todo en una sola petición HTTP. No hay panel que abrir, no hay copiar y pegar.

Paso a paso: cómo integrar tu motor con AutoSES

1. Genera la clave API

En Mi cuenta → pestaña API REST, pulsa «Generar clave». Recibirás una clave con el formato as_live_… (prefijo as de AutoSES). Solo se muestra una vez: cópiala a una variable de entorno de tu servidor antes de cerrar la pantalla.

2. Llama al endpoint de creación de reserva

Desde tu backend, realiza la petición con la clave en la cabecera Authorization:

POST /api/v1/camping/reservations
Authorization: Bearer as_live_…
Content-Type: application/json
Idempotency-Key: pedido-7821

{
  "parcela_id": 12,
  "check_in": "2026-09-01",
  "check_out": "2026-09-05",
  "adults": 2,
  "children": 1,
  "pets": 1,
  "guest": {
    "first_name": "María",
    "last_name": "García",
    "email": "maria@example.com"
  },
  "send_email": false
}

La respuesta incluye el id de la reserva, su estado inicial (G si SES está disponible y la notificación se envió con éxito, o P si SES la aceptó de inmediato), y la checkin_url.

3. Incluye la URL de check-in en tu email de confirmación

Con "send_email": false, AutoSES no contacta al campista: tú gestionas ese email. Añade checkin_url en el cuerpo del email de confirmación de tu motor. El campista pincha el enlace, rellena sus datos en su idioma y escanea el documento. A partir de ahí, el flujo es automático.

Si prefieres que AutoSES envíe el email de check-in, usa "send_email": true.

Idempotencia: reintentos sin reservas duplicadas

Las redes son imperfectas. Si tu servidor no recibe la respuesta y reintenta, sin protección crearías dos reservas para el mismo campista. La cabecera Idempotency-Key resuelve esto: asocia el intento a una cadena única de tu sistema (por ejemplo, el id del pedido). Si la misma clave llega de nuevo, la API devuelve la respuesta original sin crear ningún registro adicional.

Idempotency-Key: pedido-reserva-7821

Las claves se conservan 24 horas y son únicas por propietario.

Modo transparente: el campista nunca sabe que existe AutoSES

Si tu plataforma tiene su propia identidad de marca y quieres que el campista no reciba ningún email de AutoSES —ni el check-in ni el recibo final de estancia—, activa el modo transparente en Mi cuenta → API REST.

Con el modo transparente activado:

• AutoSES no envía ningún email al campista. Tu motor gestiona toda la comunicación.
• El envío a SES.hospedajes se realiza siempre, garantizando el cumplimiento legal.
• La copia de notificaciones al propietario (si está activada) se mantiene.

Ciclo completo de la reserva

Una vez creada desde la API, la reserva sigue el mismo ciclo que cualquier otra reserva del panel:

• G — Guardada. Notificación a SES pendiente (el scheduler reintenta cada 2 horas).
• P — Reserva enviada a SES. El campista tiene la URL de check-in pero aún no la ha completado.
• F — Parte completado. El campista rellenó sus datos; listo para enviarse a SES.
• E — Parte enviado. El campista está esperado.
• I — Alojado. El campista ha hecho check-in presencial.
• O — Finalizada. Se emite el recibo al campista (salvo modo transparente activo).
• C — Cancelada. La notificación en SES queda anulada.

Webhooks: reacciona a los eventos en tiempo real

Además de crear reservas, tu sistema puede enterarse al instante de lo que ocurre con cada una sin tener que consultar la API en bucle. Desde Mi cuenta → Integraciones registras una URL HTTPS y AutoSES te envía un POST firmado (HMAC-SHA256) cada vez que se produce un evento: reservation.created, reservation.status_changed, guest.checked_in (el campista completa el parte), ses.submission_succeeded / ses.submission_failed, balance.low, receipt.sent y más.

Es el patrón que esperan los PMS y channel managers modernos: en lugar de polling, recibes push. Cada entrega incluye la cabecera X-Autoses-Signature para verificar el origen, se reintenta con backoff exponencial (hasta 8 veces) y deduplica por el campo id. Tienes ejemplos de verificación de firma en Python, PHP y Node.js en el manual de la API (PDF).

Barrera automática: abre el acceso con la matrícula del campista

La integración no termina en la reserva. Con el endpoint POST /api/v1/camping/access/plate puedes conectar un lector de matrículas (cámara LPR/ANPR) con la barrera de entrada del camping. Cuando un coche llega, la cámara lee la matrícula, la consulta a AutoSES y la barrera se abre sola si el vehículo corresponde a una reserva activa. El campista entra sin pasar por recepción, incluso de madrugada.

POST /api/v1/camping/access/plate
Authorization: Bearer as_live_…
Content-Type: application/json

{"plate": "1234ABC"}

→ {"authorized": true, "plate": "1234ABC",
   "reservation": {"id": 42, "parcela": "A-14", "status": "I", ...}}

Se autoriza el acceso si la matrícula pertenece a una reserva en estado E (parte enviado, huésped esperado) o I (alojado) con la fecha de hoy dentro de la estancia. Cada reserva admite hasta 3 matrículas —los tres vehículos— y cualquiera de ellas abre la barrera. La comparación normaliza la matrícula (ignora mayúsculas, espacios y guiones) y el filtro por estado y fecha evita que una reserva antigua de un cliente habitual con la misma matrícula abra el acceso por error. La respuesta es siempre 200: tu sistema de barrera decide abrir según el campo authorized.

Documentación y próximos pasos

La documentación interactiva completa está en /api/v1/docs (Swagger UI con try-it-out). El esquema OpenAPI descargable está en /api/v1/openapi.json.

Para una visión general de la integración y los casos de uso más habituales, visita la página API REST para motor de reservas de camping.