Ctrlk
Go to Yoplanning.pro
For the complete documentation index, see llms.txt. This page is also available as Markdown.

API OCTO Yoplanning - Workflow de vente standard

Presentación

Yoplanning ofrece una implementación de la API de OCTO para permitir la reventa de actividades entre equipos.

Esta documentación presenta el flujo de trabajo estándar para ventas, cancelaciones y notificaciones webhook.

Esta implementación cumple con los estándares de OCTO Travel. Certificación oficial de OCTO

Documentación oficial de OCTO: https://docs.octo.travel/

Requisitos previos

Antes de utilizar la API de OCTO Yoplanning, deben estar implementadas las siguientes configuraciones en Yoplanning:

  • Un equipo de reventa (teamId)

  • Un equipo de proveedores (providerId)

  • Un token de API de tipo run user creado en el equipo de reventa

  • El proveedor debe:

    • tras haber incorporado al revendedor a su equipo.

    • una vez configurados los productos disponibles para su reventa

URL base

Variables

Variable
Descripción

<teamId>

ID del equipo de revendedores

<proveedorId>

ID del equipo del proveedor

Autenticación

La autenticación funciona igual que la API de Yoplanning v3.1.

Puedes usar:

Token de autorización de encabezado

Portador de autorización de encabezado

Capacidades utilizadas

Todas las solicitudes utilizan las siguientes capacidades:

Estas capacidades le permiten recuperar:

  • información de precios

  • contenido de marketing de productos

  • datos descriptivos sobre disponibilidad

Flujo de trabajo estándar compatible

El flujo de trabajo estándar compatible con Yoplanning es el siguiente:

Proceso de cancelación:

Flujo de trabajo de notificación:

1. Recuperar los productos

Punto final:

Este punto final le permite recuperar los productos disponibles para la venta.

Usar

El revendedor utiliza esta ruta para:

  • mostrar el catálogo del proveedor

  • recuperar las opciones

  • recuperar las unidades arancelarias

  • mostrar contenido de marketing

2. Mostrar un calendario de disponibilidad (opcional)

Punto final:

Este paso es opcional.

Te permite mostrar:

  • fechas disponibles

  • precios “desde”

  • un calendario de reservas

Mejores prácticas

Utilice esta ruta para:

  • mostrar un calendario mensual

  • Disponibilidad de precarga

  • mejorar el rendimiento frontal

3. Consultar disponibilidad

Punto final:

Este paso es obligatorio.

Te permite recuperar:

  • los horarios disponibles

  • los horarios

  • las capacidades

  • los precios exactos

  • el availableId

El availabilityId es necesario para crear una reserva.

Recomendación importante

La mejor manera es transmitir las unidades (número de participantes).

Esto permite:

  • para obtener el mejor precio

  • para recuperar la buena disponibilidad

  • para calcular correctamente las capacidades

4. Reservar asientos

Punto final:

Esta ruta crea una reserva temporal.

El pedido se crea con el estado:

El estado ON_HOLD significa:

  • Los asientos están bloqueados.

  • La reserva aún no está confirmada.

  • El pedido caduca automáticamente a los 30 minutos si no se confirma.

Importante

En esta etapa:

  • La reserva ya existe.

  • Los espacios son seguros.

  • El pago puede ser finalizado por el revendedor.

5. Confirmar el pedido

Punto final:

Este paso finaliza la reserva.

Una vez confirmado:

  • La orden se vuelve definitiva

  • Se pueden generar boletos

  • La reserva está completa.

Importante

La confirmación es sencilla:

  • Solo confirma el pedido existente.

  • No es posible modificar el contenido del pedido en esta etapa.

6. Cancelar un pedido

Punto final:

Esta ruta le permite cancelar una reserva.

Importante

Asegúrese de respetar la política de cancelación del proveedor si la reserva ya está confirmada.

Según las normas del proveedor:

  • Pueden aplicarse tarifas.

  • La cancelación puede estar prohibida.

  • Pueden existir condiciones específicas

El revendedor debe consultar las normas de cancelación antes de ofrecer la acción al cliente final.

Ampliar la reserva (opcional)

Punto final:

Esta ruta permite extender la duración del estado ON_HOLD.

Ejemplo :

  • pago pendiente

  • Validación del cliente en curso

  • Se necesita tiempo adicional

La reserva debe seguir siendo válida en el momento de la llamada.

Notificaciones de webhook

Punto final:

Esta ruta le permite registrarse para recibir webhooks de OCTO.

Los webhooks te permiten recibir notificaciones sobre:

  • los productos

  • disponibilidad

  • reservas

Marcha

Los datos completos del objeto no se envían directamente al webhook.

El webhook contiene la información necesaria para recuperar los puntos finales relevantes y obtener las actualizaciones.

Mejores prácticas

Después de recibir un webhook:

  • recordar el punto final en cuestión

  • recargar los datos más recientes

  • No utilice el webhook como su fuente de datos completa.

Gestionar la caducidad de las reservas

Una reserva no confirmada se elimina automáticamente al expirar.

Por defecto:

Por lo tanto, el revendedor debe:

  • Confirmar pedidos rápidamente

  • Gestionar correctamente los plazos de pago

  • Utilice /extend si es necesario.

Mejores prácticas

Utilice siempre /availability.

Aunque utilice /availability/calendar, aún necesita llamar a:

antes de /booking.

Esta ruta proporciona el availabilityId necesario para la reserva.

Enviar las unidades arancelarias

Transmita siempre las unidades (unidades / participantes).

Esto mejora:

  • cálculo de tarifas

  • disponibilidad

  • las reglas de capacidad

Controlar las exhalaciones en la parte frontal

Muestra un temporizador visible cuando el comando está en ON_HOLD.

Recargar datos después del webhook

Los webhooks se utilizan exclusivamente para notificaciones.

Recargue siempre los datos a través de los puntos finales de la API correspondientes.

Documentación oficial de OCTO

Aquí encontrará información detallada sobre los puntos finales y la arquitectura de OCTO:

https://docs.octo.travel/

AnteriorBrique technologique de planificationSiguienteFAQ développeur

Última actualización