Descripción General
La integración de socios de Launch Pad permite que tu plataforma incorpore planificación de rutas, optimización de recorridos y operaciones de campo sin necesidad de construir ni operar los sistemas subyacentes. Cuatro niveles de integración van desde un simple enlace profundo hasta la federación completa de identidad, todos respaldados por una API REST pública y autenticación OAuth 2.0 basada en estándares.
Cada nivel funciona de forma independiente. La mayoría de los socios comienzan en el Nivel 1 (Lanzamiento con Un Clic) y agregan niveles superiores más adelante según cambien sus necesidades. Las secciones siguientes describen lo que experimentan tus usuarios finales, lo que obtienes como empresa, el desglose completo de los cuatro niveles y un análisis detallado del Nivel 1. La sección de Detalle Técnico más adelante contiene la especificación de ingeniería.
Portal del Desarrollador & Referencia de la API
Referencia completa de la API REST, patrones de autenticación y guías de inicio para la API pública de Launch Pad. Consulta este recurso cuando comiences a evaluar cualquier nivel superior al Nivel 1, o cuando necesites detalles a nivel de endpoint más allá de lo que cubre esta página.
Visitar el Portal del DesarrolladorLo Que Experimentan Tus Usuarios
En el Nivel 1, Launch Pad actúa como una aplicación complementaria a tu producto. Se abre en una nueva ventana del navegador con toda la configuración realizada en segundo plano, para que el usuario pueda comenzar a trabajar de inmediato.
Sin Nuevo Registro
Los usuarios no crean una cuenta en Launch Pad. Su identidad proviene de tu producto.
Sin Segundo Inicio de Sesión
Los usuarios inician sesión automáticamente cuando abren Launch Pad desde tu aplicación.
Sin Carga de Archivos Para Empezar
El lote correcto y su contorno ya están cargados cuando el usuario llega. El manejo de lotes es uno de los mayores obstáculos cuando los productores adoptan herramientas agrícolas externas; un flujo de "hipervínculo, iniciar sesión, cargar archivo" pierde la mayor parte del valor que una integración debería entregar.
Retorno del Resultado (Manual al Inicio)
Cuando los usuarios terminan, descargan el archivo del plan de rutas de Launch Pad y lo cargan en tu producto. Un lugar natural para automatizar más adelante mediante Webhook push o una integración de Custom push, reutilizando el cliente de API que ya construiste para el Nivel 1.
Lo Que Obtienes Como Socio
Diseñado para empresas y equipos de ingeniería que quieren incorporar enrutamiento de precisión sin montar la infraestructura necesaria para respaldarlo.
Una Identidad de Administrador
Un único usuario administrador es tu identidad dentro de Launch Pad. Ese mismo usuario tiene la clave de API para llamadas de servidor a servidor y puede iniciar sesión directamente en Launch Pad para inspeccionar, auditar o dar soporte a un cliente.
Facturación Consolidada
Todo el uso se consolida en una sola cuenta de facturación del socio. Los usuarios finales nunca ven saldos de crédito ni facturas dentro de Launch Pad. Tú eres la parte facturada; el precio es por volumen y se negocia.
Vista de Admin entre Clientes
Tu administrador ve el uso, los planes, los lotes y la actividad por usuario de cada cliente que incorporas, todo en un solo lugar. Es la visibilidad que necesitas para dar soporte a los clientes y conciliar la facturación.
Cuatro Niveles de Integración
Cada nivel funciona de forma independiente. La mayoría de los socios comienzan en el Nivel 1 y agregan niveles superiores más adelante según cambien sus necesidades.
Nivel 1: Lanzamiento con Un Clic
Los usuarios abren Launch Pad desde tu producto sin registrarse, iniciar sesión ni cargar un lote. El lote correcto ya aparece en pantalla. El archivo del plan de rutas terminado regresa a tu producto a través de tu flujo actual de importación de archivos.
Tú construyes: llamadas de API para crear el usuario, solicitar un enlace de lanzamiento, enviar el lote y redirigir el navegador. Tu flujo actual de importación de archivos acepta el archivo devuelto.
Nivel 2: Integración por API
Acceso programático completo a empresas, productores, granjas, lotes, contornos, planes de rutas y recorridos mediante una API REST. Notificaciones de eventos en acciones clave.
Tú construyes: una capa de sincronización entre tu producto y Launch Pad. Un receptor de webhook (preferido) o polling programado para el camino de retorno.
Nivel 3: UI Integrada
Pantallas de Launch Pad mostradas dentro de tu producto, en un iframe. Navegación oculta, con los colores de tu marca.
Tú construyes: un host de iframe. Un pequeño handshake para pasar los colores de tu marca.
Nivel 4: Federación de Identidad
"Iniciar sesión con Launch Pad" (o a la inversa) usando OpenID Connect basado en estándares. El consentimiento del usuario final y la vinculación de cuentas son gestionados por Launch Pad.
Tú construyes: una biblioteca cliente de OpenID Connect y un almacén de tokens.
Cómo el Nivel 1 Elimina la Fricción
Por Qué Existe el Nivel 1
El Nivel 1 es la diferencia entre una integración y un hipervínculo. Desde la perspectiva del usuario, la Planificación de Rutas es parte de tu producto: hace clic en un botón, realiza la tarea y trae el resultado de vuelta.
Para lograrlo, el Nivel 1 elimina los dos momentos de mayor fricción al adoptar una herramienta agrícola externa:
- Configuración de cuenta (registro, inicio de sesión, selección de empresa). Tu backend crea e inicia sesión del usuario en segundo plano.
- Carga del lote. Tu backend envía el lote a Launch Pad a través de la API antes de abrir la ventana, de modo que el usuario llega con el lote correcto ya en pantalla.
El manejo de lotes es el más impactante de los dos. Es uno de los mayores obstáculos cuando los productores adoptan herramientas agrícolas externas.
Modelo de Cuenta
Un compromiso de Nivel 1 se organiza de la siguiente manera:
Tu identidad en Launch Pad es un único usuario administrador
Este usuario tiene tu clave de API, tiene visibilidad administrativa en todas las organizaciones de cliente que crees, y también puede iniciar sesión directamente en Launch Pad para inspeccionar, auditar o dar soporte a un cliente. Los usuarios finales nunca ven a este usuario.
Cada cliente se convierte en su propia organización dentro de Launch Pad
Poblada con los usuarios finales que tú creas. Un usuario final solo ve su propia organización; nunca ve los datos de clientes de otros socios.
La facturación se consolida en tu cuenta de facturación
Los usuarios finales nunca ven saldos de crédito ni facturas dentro de Launch Pad; tú eres la parte facturada.
Vista de admin entre clientes
Tu usuario administrador ve el uso por organización de cliente, recuentos de planes y lotes, y la actividad por usuario de cada cliente en un solo lugar. Es la visibilidad que necesitas para dar soporte a los clientes y conciliar la facturación.
Lo Que los Usuarios Ven en Launch Pad
Cuando un usuario abre Launch Pad a través del Nivel 1, algunas opciones de Launch Pad no aplican y están ocultas:
- Sin cambio de contraseña, sin gestión de correo electrónico ni cuenta, sin registro. El usuario no tiene contraseña de Launch Pad; el inicio de sesión proviene de tu producto. La pantalla de cambio de contraseña muestra un mensaje "Contraseña gestionada por [Socio]", de la misma forma en que Launch Pad ya gestiona a los usuarios que inician sesión a través de John Deere, Trimble o CNH.
- Sin selector de empresa. La sesión está bloqueada a una única organización de cliente para esa visita.
- El cierre de sesión es reemplazado por "Volver a [Socio]", que cierra la pestaña o envía al usuario de vuelta a una URL que tú proporcionas, en lugar de dejarlo en la página de inicio de sesión de Launch Pad.
El menú principal de trabajo (Planes, Planificación de Rutas, Equipos, Comparar) sigue disponible porque los usuarios lo necesitan para realizar la tarea. Solo se ocultan las opciones de identidad, facturación, administración y gestión de cuentas.
Devolución del Plan de Rutas
Una vez que un usuario termina un plan de rutas en Launch Pad, el resultado necesita volver a tu producto. Hay cuatro opciones disponibles que funcionan sobre cualquier nivel. Las opciones de push son fuertemente preferidas sobre el polling.
Descarga / Carga Manual
El usuario hace clic en Descargar en Launch Pad y luego carga el archivo en tu producto.
Mejor cuando: es la forma más rápida de empezar.
Webhook Push
Launch Pad envía cada plan terminado a una URL que tú proporcionas, firmado con HMAC.
Mejor cuando: quieres entrega en tiempo real y puedes alojar un endpoint genérico de webhook.
Custom Push
Verge escribe una integración a medida que entrega los planes terminados directamente en tu API existente.
Mejor cuando: tienes una API entrante que acepta credenciales, pero no quieres construir un receptor de webhook.
Polling Pull
Tu backend obtiene periódicamente los planes terminados desde la API de Launch Pad.
Mejor cuando: ninguna opción de push es viable. La cadencia debe ser conservadora.
Prerrequisito obligatorio para la descarga/carga manual: tu flujo de importación debe aceptar al menos un formato que emite Launch Pad (ISOXML, Shapefile, KML o formatos específicos del socio; confirmado durante el alcance). Sin esta superposición, el Nivel 1 no puede entregar un flujo de extremo a extremo utilizable.
Detalle Técnico
Un lector no técnico puede detenerse aquí. El resto de esta página es la especificación de ingeniería: flujo de extremo a extremo, anatomía de la URL de redirección y mecánica del camino de retorno.
Flujo de Extremo a Extremo
Lo que ocurre, paso a paso, cuando un usuario del socio abre Launch Pad:
sequenceDiagram
autonumber
participant YU as UI del Socio
participant YB as Backend del Socio
participant LA as Launch Pad API
participant LU as Launch Pad UI
YU->>YB: usuario hace clic en "Abrir Plan de Rutas"
note over YB,LA: Paso 1: crear usuario de LP si no existe
YB->>LA: POST /api/users (idempotente en externalUserId)
YB->>LA: POST /api/company-accesses (idempotente en usuario + org)
note over YB,LA: Paso 2 (opcional): enviar un lote
YB->>LA: POST /api/vBoundary/upsert
note over YB,LA: Paso 3: solicitar un código de lanzamiento
YB->>LA: POST /api/partner/launch ({ userId, companyId, returnUrl })
LA-->>YB: { code, expiresInSec: 600 }
YB-->>YU: 302 redirige a https://your-app.vergeag.com/launch?code=...
YU->>LU: el navegador navega a /launch?code=...
LU->>LA: POST /api/partner/launch/{code}/exchange
LA-->>LU: JWT + refresh token
note over LU: almacena JWT en localStorage,
elimina código de la URL,
navega a returnUrl
Propiedades Clave
- Te autenticas de servidor a servidor con una credencial de larga duración (la clave de API de tu usuario administrador). El navegador nunca ve la clave de API.
- El navegador solo ve un código opaco, de un solo uso y de corta duración en la URL (tiempo de vida de 10 minutos, consumido al intercambiarse).
- El endpoint de intercambio no requiere inicio de sesión; el código en sí es la credencial. La UI de Launch Pad lo llama en cuanto el usuario llega.
- Launch Pad emite una sesión de usuario normal (JWT + refresh token), la almacena en localStorage y enruta al usuario a la URL que especificaste.
Alineación con Estándares
El patrón es el OAuth 2.0 Authorization Code Grant, con la pantalla interactiva de consentimiento reemplazada por una llamada de autorización de servidor a servidor desde tu backend. La terminología moderna de OAuth denomina esta variante de canal posterior Pre-Authorized Code Flow (introducido en la especificación OpenID for Verifiable Credential Issuance).
El código de corta duración en la URL y el intercambio por un JWT a través del canal posterior se comportan exactamente igual que en el OAuth de libro de texto; el consentimiento se establece mediante el acuerdo de asociación en lugar de un diálogo de consentimiento por lanzamiento.
Cómo Es la URL de Redirección
Lo que recibe el navegador del usuario (una línea, como encabezado Location:):
https://your-app.vergeag.com/launch?code=lc_R3w9q-Kx7VtNm2bH8sLpYj4eQ6gZc1aXfU0dT5nMoP&returnUrl=%2Fpath-planning%2Fboundary%2Fb3f47e1c-8a02-4d59-9c6e-2f7a8b1d6e09
Decodificada para mayor legibilidad:
| Componente | Valor | Notas |
|---|---|---|
| Origen | https://your-app.vergeag.com |
Verge proporciona el origen de producción durante el onboarding. HTTPS es obligatorio; HTTP plano es rechazado. |
| Ruta | /launch |
Ruta pública no autenticada. No se requiere sesión previa de Launch Pad. |
code |
lc_R3w9q-... |
El prefijo lc_ identifica este valor como código de lanzamiento (distinto de una clave de API LP- en los registros). El payload son 32 bytes de aleatoriedad criptográfica, codificados en base64url. De un solo uso, TTL de 10 minutos, vinculado en el momento de emisión a un usuario, una organización y un returnUrl. |
returnUrl |
/path-planning/boundary/... |
La ruta relativa de Launch Pad a la que se envía al usuario después de emitir el JWT. Usa segmentos de ruta (por ejemplo, /path-planning/boundary/:id) para que el lote se cargue automáticamente. Debe comenzar con /. Las URL absolutas, las URL relativas al protocolo //host y \ son rechazadas en el momento de la emisión. |
Lo Que Hace la UI de Launch Pad al Llegar
Tú no implementas esto; se incluye como referencia para que puedas razonar sobre lo que ven tus usuarios entre el clic y el lote renderizado:
- Lee
codeyreturnUrlde la cadena de consulta. - Intercambia el código con Launch Pad por una sesión de usuario.
- Inicia sesión del usuario en la organización de cliente correcta.
- Elimina el código de la barra de direcciones para que no quede en el historial del navegador.
- Envía al usuario al
returnUrlque especificaste.
Si code falta, está vencido o ya fue usado, el usuario llega a una página de error que le pide volver a tu producto e intentarlo de nuevo.
Opciones de Devolución en Detalle
Descarga / Carga Manual
El usuario hace clic en Descargar en Launch Pad, el archivo llega a su dispositivo y lo carga en tu producto a través de tu flujo actual de importación de archivos. Predeterminado para el Nivel 1. Sin infraestructura nueva de tu lado. Requiere que tu flujo de importación acepte al menos un formato que emite Launch Pad (ISOXML, Shapefile, KML o formatos específicos del socio).
Webhook Push
Launch Pad envía POSTs HTTPS a una URL que tú proporcionas. Cada solicitud lleva una firma HMAC-SHA256, calculada contra un secreto compartido que Verge emite en el onboarding. Verificas la firma, procesas el payload y respondes con un 2xx en 10 segundos.
Propiedades Clave
- No te autenticas en Launch Pad para este flujo. Sin handshake OAuth, sin JWT, sin clave de API de Launch Pad de tu lado. El secreto HMAC compartido es todo el modelo de autenticación.
- Un secreto por suscripción, rotable. Emitido una vez en el onboarding. La rotación usa una ventana de superposición de dos secretos para que las entregas no fallen durante el corte.
- La entrega de archivos escala con el tamaño del payload. Los artefactos pequeños (menos de 1 MB) se envían inline como base64 dentro del cuerpo del webhook. Los artefactos más grandes se envían como una URL de descarga presignada de corta duración incrustada en el cuerpo; haces GET a esa URL directamente, sin necesidad de credenciales de Launch Pad.
-
Entrega at-least-once. Launch Pad reintenta con backoff exponencial en respuestas no-2xx y timeouts. Cada evento lleva un encabezado
Verge-Webhook-Idpara que puedas deduplicar.
Lo Que Tú Construyes
- Un endpoint HTTPS público que acepta POSTs. No se requiere inicio de sesión ni sesión en el endpoint más allá de verificar la firma.
- Verificación HMAC usando el secreto compartido (alrededor de diez líneas de código en cualquier lenguaje).
- Una comprobación de idempotencia en
Verge-Webhook-Idpara que un reintento nunca procese dos veces. - Una respuesta 2xx rápida. Procesa cualquier trabajo pesado de forma asíncrona para que los timeouts no desencadenen tormentas de reintentos.
Lo Que Verge Opera
- El emisor de salida y la cola de reintentos.
- El manejo de dead-letter para entregas permanentemente fallidas.
- Una UI de administración para que veas los registros de entrega y reproduzcas eventos fallidos.
- Un conjunto publicado de rangos de IP de salida que puedes permitir en el firewall.
Custom Push (ingeniería por socio)
Si ya tienes una API entrante autenticada pero no quieres construir un receptor genérico de webhook, Verge puede escribir una integración de push a medida que llama a tu API directamente. Compartes credenciales seguras con Verge (preferiblemente una clave de API); el emisor de Verge se autentica contigo en cada push.
Esta opción existe por una asimetría en la dirección de confianza. Para los grandes socios FMIS (John Deere, Trimble, CNH), los usuarios finales se autentican en Launch Pad con su cuenta OEM, por lo que Launch Pad ya tiene tokens seguros para devolver datos. Launch Pad opera ese modelo de OEM push hoy en día. En una integración de Nivel 1, la dirección de confianza se invierte (tú te autenticas en Launch Pad), por lo que Launch Pad no tiene credenciales preexistentes hacia tu sistema. Custom push cierra esa brecha con un acuerdo a medida.
Compensaciones
- Ingeniería a medida del lado de Verge. La API de cada socio es diferente. Este es trabajo por socio, no una característica genérica, y el precio lo refleja.
- Acuerdo de socio de confianza. Compartes una clave de API (o credencial segura equivalente) con Verge y operas esa credencial de tu lado.
- Mantenimiento conjunto. Ambas partes mantienen la integración funcionando a través de cambios de API y rotaciones de credenciales.
Adecuado cuando tienes una API entrante existente, no quieres construir un receptor genérico de webhook y tienes suficiente compromiso para financiar el trabajo por socio.
Polling Pull (usar con moderación; push es preferido)
Si ninguna opción de push es viable, tu backend puede llamar periódicamente a la API de Launch Pad (usando la misma X-API-KEY ya emitida para el aprovisionamiento) para obtener los planes de rutas publicados o actualizados desde la última consulta.
Trátalo como recuperación por lotes eventualmente consistente, no como entrega en tiempo real. Una cadencia típica es horaria o menos frecuente. El polling de alta frecuencia que se asemeje a un busy-wait contra una acción del usuario no está soportado y puede ser limitado por rate limiting. Hacer polling continuamente durante horas esperando un único evento iniciado por el usuario es exactamente el patrón que esta opción no cubre.
- Lo que tú construyes: un bucle de polling con cadencia conservadora, deduplicación por ID del plan de rutas e ingesta en tu almacén de archivos.
- Compensación: latencia significativa entre la acción del usuario y la llegada de los datos; carga adicional sobre la API de Launch Pad.
- Push es fuertemente preferido. Usa polling solo cuando ni el Webhook push ni el Custom push sean viables.
Niveles Superiores
Esta página es la referencia completa para el Nivel 1. Para los niveles superiores:
Nivel 2 (Integración por API)
El esquema público de la API está en vergeag.com/developers. Una vez que el Nivel 1 esté en su lugar, puedes expandir la integración llamando a más de la API directamente, usando la misma clave de API que ya tienes.
Nivel 3 (UI Integrada)
Contacta a Verge para dimensionar el alcance. La UI Integrada implica acuerdos de brand tokens, configuración de host de iframe y un build de la UI por socio. No es self-service.
Nivel 4 (Federación de Identidad)
Contacta a Verge para dimensionar el alcance. La Federación de Identidad requiere registro de cliente OIDC basado en estándares y un acuerdo de federación entre ambas partes.