> For the complete documentation index, see [llms.txt](https://docs.yoplanning.support/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.yoplanning.support/es/developpeur/api-octo-yoplanning-workflow-de-vente-standard.md). # 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](https://certify.octo.travel/verify/5065485c-5142-4814-91b7-1dd63777a741) Documentación oficial de OCTO: *** ### 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 ``` https://yoplanning.pro/api/octo/teams//providers// ``` #### Variables | Variable | Descripción | | --------------- | ----------------------------- | | `` | ID del equipo de revendedores | | `` | 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 ```http Authorization: Token XXXX ``` #### Portador de autorización de encabezado ```http Authorization: Bearer XXXX ``` *** ### Capacidades utilizadas Todas las solicitudes utilizan las siguientes capacidades: ```http Octo-Capabilities: pricing,content ``` 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: ``` /products ↓ /availability/calendar (optionnel) ↓ /availability ↓ /booking ↓ /confirm ``` Proceso de cancelación: ``` /cancel ``` Flujo de trabajo de notificación: ``` /notifications/subscriptions ``` *** ### 1. Recuperar los productos Punto final: ```http GET /products ``` 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: ```http POST /availability/calendar ``` 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: ```http POST /availability ``` 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: ```http POST /booking ``` Esta ruta crea una reserva temporal. El pedido se crea con el estado: ``` ON_HOLD ``` 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: ```http POST /confirm ``` 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: ```http POST /cancel ``` 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: ```http POST /extend ``` 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: ```http POST /notifications/subscriptions ``` 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: ``` 30 minutes ``` 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: ```http /availability ``` 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: --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.yoplanning.support/es/developpeur/api-octo-yoplanning-workflow-de-vente-standard.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.