Огляд
Партнерська інтеграція Launch Pad дозволяє вашій платформі вбудовувати планування маршрутів, оптимізацію маршрутів і польові операції, не створюючи й не обслуговуючи базові системи. Чотири рівні інтеграції варіюються від простого глибокого посилання до повної федерації посвідчень — усі засновані на публічному REST API та стандартній автентифікації OAuth 2.0.
Кожен рівень працює самостійно. Більшість партнерів починають з рівня 1 (запуск одним кліком) і додають вищі рівні пізніше, в міру зміни потреб. У розділах нижче описується досвід ваших кінцевих користувачів, що ви отримуєте як бізнес, повний розбір усіх чотирьох рівнів і детальний аналіз рівня 1. Розділ Технічні деталі далі містить технічну специфікацію.
Портал розробника & довідник по API
Повний довідник REST API, шаблони автентифікації та посібники з початку роботи для публічного API Launch Pad. Звертайтесь до цього ресурсу, коли починатимете оцінювати будь-який рівень вище рівня 1, або коли вам потрібні деталі на рівні кінцевих точок, що виходять за межі цієї сторінки.
Перейти до порталу розробникаЩо бачать ваші користувачі
На рівні 1 Launch Pad працює як супутній застосунок до вашого продукту. Він відкривається в новому вікні браузера, при цьому вся підготовка виконується у фоновому режимі, тож користувач може одразу приступити до роботи.
Немає нової реєстрації
Користувачі не створюють обліковий запис у Launch Pad. Їхнє посвідчення береться з вашого продукту.
Немає повторного входу
Користувачі входять в систему автоматично при відкритті Launch Pad з вашого застосунку.
Немає завантаження файлів для початку роботи
Потрібне поле та його межа вже завантажені, коли користувач потрапляє в систему. Робота з межами полів є одним з головних бар'єрів при освоєнні зовнішніх аграрних інструментів; схема «посилання, вхід, завантаження файлу» знищує більшу частину цінності, яку мала б дати інтеграція.
Зворотній шлях (спочатку вручну)
Коли користувачі закінчують роботу, вони завантажують файл плану маршруту з Launch Pad і вивантажують його у ваш продукт. Природне місце для подальшої автоматизації через Webhook push або інтеграцію Custom push, повторно використовуючи API-клієнт, уже створений для рівня 1.
Що отримуєте ви як партнер
Створено для бізнесу та інженерних команд, які хочуть вбудовувати точну маршрутизацію, не будуючи інфраструктуру для її підтримки.
Один адміністративний обліковий запис
Єдиний адміністратор — це ваша ідентичність усередині Launch Pad. Цей самий користувач зберігає API-ключ для викликів сервер-сервер і може входити в Launch Pad напряму, щоб перевіряти, аудіювати або підтримувати клієнта.
Консолідовані розрахунки
Все використання збирається в єдиному партнерському білінговому обліковому записі. Кінцеві користувачі ніколи не бачать залишки кредитів або рахунки всередині Launch Pad. Ви — платник; ціна залежить від обсягу і узгоджується індивідуально.
Зведений адміністративний перегляд по клієнтах
Ваш адміністратор бачить використання, плани, межі та активність кожного користувача по всіх підключених клієнтах в одному місці. Це саме та прозорість, яка потрібна для підтримки клієнтів і звірки розрахунків.
Чотири рівні інтеграції
Кожен рівень працює самостійно. Більшість партнерів починають з рівня 1 і додають вищі рівні пізніше, в міру зміни потреб.
Рівень 1: запуск одним кліком
Користувачі відкривають Launch Pad з вашого продукту без реєстрації, входу або завантаження межі поля. Потрібне поле вже відображається на екрані. Готовий файл плану маршруту повертається у ваш продукт через наявний потік імпорту файлів.
Ви створюєте: API-виклики для створення користувача, запиту посилання для запуску, передачі межі та переадресації браузера. Ваш наявний потік імпорту файлів приймає повернений файл.
Рівень 2: інтеграція через API
Повний програмний доступ до компаній, фермерів, господарств, полів, меж, планів маршрутів і маршрутів через REST API. Повідомлення про події при ключових діях.
Ви створюєте: шар синхронізації між вашим продуктом і Launch Pad. Приймач webhook (бажано) або заплановане опитування для зворотнього шляху.
Рівень 3: вбудований інтерфейс
Екрани Launch Pad відображаються всередині вашого продукту в iframe. Навігація прихована, використовуються кольори вашого бренду.
Ви створюєте: хост для iframe. Невеликий обмін для передачі кольорів вашого бренду.
Рівень 4: федерація посвідчень
«Увійти через Launch Pad» (або навпаки) із використанням стандартного OpenID Connect. Згода кінцевого користувача та прив'язка акаунтів управляються Launch Pad.
Ви створюєте: клієнтську бібліотеку OpenID Connect і сховище токенів.
Як рівень 1 усуває тертя
Навіщо потрібен рівень 1
Рівень 1 — це різниця між справжньою інтеграцією і звичайним гіперпосиланням. З точки зору користувача, планування маршрутів є частиною вашого продукту: він натискає кнопку, виконує завдання і повертає результат.
Щоб це працювало, рівень 1 усуває два найболючіших моменти при освоєнні зовнішнього аграрного інструменту:
- Налаштування облікового запису (реєстрація, вхід, вибір компанії). Ваш бекенд створює та авторизує користувача у фоновому режимі.
- Завантаження межі поля. Ваш бекенд надсилає межу в Launch Pad через API до відкриття вікна, тож користувач потрапляє одразу з потрібним полем на екрані.
Робота з межами полів — найвагоміший з двох бар'єрів. Це один з головних перешкод при освоєнні зовнішніх аграрних інструментів фермерами.
Модель облікового запису
Взаємодія на рівні 1 організована таким чином:
Ваша ідентичність у Launch Pad — єдиний адміністратор
Цей користувач зберігає ваш API-ключ, має адміністративний доступ до всіх створених вами організацій клієнтів, а також може входити в Launch Pad напряму для перевірки, аудіювання або підтримки клієнта. Кінцеві користувачі цього користувача не бачать.
Кожен клієнт стає окремою організацією всередині Launch Pad
Наповнюється кінцевими користувачами, яких ви створюєте. Кінцевий користувач бачить лише свою організацію і ніколи не бачить дані клієнтів інших партнерів.
Розрахунки консолідовані у вашому білінговому обліковому записі
Кінцеві користувачі ніколи не бачать залишки кредитів або рахунки всередині Launch Pad; платник — ви.
Зведений адміністративний перегляд по клієнтах
Ваш адміністратор бачить використання по організаціях клієнтів, кількість планів і меж, а також активність кожного користувача — все в одному місці. Це саме та прозорість, яка потрібна для підтримки клієнтів і звірки розрахунків.
Що користувачі бачать у Launch Pad
Коли користувач відкриває Launch Pad через рівень 1, деякі опції Launch Pad не застосовуються і приховані:
- Немає зміни пароля, керування email або обліковим записом, немає реєстрації. У користувача немає пароля Launch Pad; вхід здійснюється через ваш продукт. На екрані зміни пароля відображається повідомлення «Пароль управляється [Партнером]» — так само, як Launch Pad вже обробляє користувачів, що входять через John Deere, Trimble або CNH.
- Немає перемикача компанії. Сесія прив'язана до єдиної організації клієнта на час візиту.
- Вихід замінено на «Повернутись до [Партнера]», що закриває вкладку або відправляє користувача назад на вказаний вами URL, замість того щоб залишати його на сторінці входу Launch Pad.
Головне робоче меню (Плани, Планування маршрутів, Обладнання, Порівняти) залишається доступним, оскільки воно потрібне користувачам для роботи. Приховані лише опції посвідчень, розрахунків, адміністрування та керування обліковим записом.
Повернення плану маршруту
Коли користувач завершує план маршруту в Launch Pad, результат потрібно повернути у ваш продукт. Доступні чотири варіанти, і вони працюють поверх будь-якого рівня. Push-варіанти значно переважніші за опитування (polling).
Завантажити і вивантажити вручну
Користувач натискає «Завантажити» в Launch Pad, потім вивантажує файл у ваш продукт.
Найкраще коли: це найшвидший спосіб почати.
Webhook Push
Launch Pad надсилає кожен готовий план на вказаний вами URL, підписаний HMAC.
Найкраще коли: вам потрібна доставка в режимі реального часу і ви можете розмістити універсальний webhook-ендпоінт.
Custom Push
Verge створює одноразову інтеграцію, яка доставляє готові плани безпосередньо у ваш наявний API.
Найкраще коли: у вас є вхідний API, що приймає облікові дані, але ви не хочете створювати приймач webhook.
Polling Pull
Ваш бекенд періодично запитує готові плани з API Launch Pad.
Найкраще коли: жоден push-варіант не застосовний. Частота запитів має бути консервативною.
Обов'язкова умова для завантаження та вивантаження вручну: ваш потік імпорту повинен приймати хоча б один формат, який видає Launch Pad (ISOXML, Shapefile, KML або партнерські формати; уточнюється при погодженні). Без цього перетину рівень 1 не забезпечить придатний до використання наскрізний потік.
Технічні деталі
Нетехнічний читач може зупинитися тут. Решта сторінки — це технічна специфікація: наскрізний потік, анатомія URL переадресації та механіка повернення.
Наскрізний потік
Що відбувається крок за кроком, коли користувач партнера відкриває Launch Pad:
sequenceDiagram
autonumber
participant YU as UI партнера
participant YB as Бекенд партнера
participant LA as Launch Pad API
participant LU as Launch Pad UI
YU->>YB: користувач натискає «Відкрити план маршруту»
note over YB,LA: Крок 1: створити користувача LP, якщо не існує
YB->>LA: POST /api/users (idempotent on externalUserId)
YB->>LA: POST /api/company-accesses (idempotent on user + org)
note over YB,LA: Крок 2 (опціонально): передати межу поля
YB->>LA: POST /api/vBoundary/upsert
note over YB,LA: Крок 3: запросити код запуску
YB->>LA: POST /api/partner/launch ({ userId, companyId, returnUrl })
LA-->>YB: { code, expiresInSec: 600 }
YB-->>YU: 302 redirect to https://your-app.vergeag.com/launch?code=...
YU->>LU: браузер переходить на /launch?code=...
LU->>LA: POST /api/partner/launch/{code}/exchange
LA-->>LU: JWT + refresh token
note over LU: зберегти JWT у localStorage,
видалити код з URL,
перейти на returnUrl
Ключові властивості
- Ви автентифікуєтесь сервер-сервер з довготривалим обліковим записом (API-ключ вашого адміністратора). Браузер ніколи не бачить API-ключ.
- Браузер бачить лише короткоживучий одноразовий непрозорий код в URL (час життя 10 хвилин, знищується при обміні).
- Ендпоінт обміну не вимагає входу; сам код є обліковим записом. UI Launch Pad викликає його, щойно користувач потрапляє на сторінку.
- Launch Pad видає звичайну користувацьку сесію (JWT + refresh token), зберігає її в localStorage і перенаправляє користувача на вказаний вами URL.
Відповідність стандартам
Патерн — це OAuth 2.0 Authorization Code Grant, де інтерактивний екран згоди замінено серверним викликом авторизації з вашого бекенду. Сучасна термінологія OAuth називає цей back-channel варіант Pre-Authorized Code Flow (введений у специфікації OpenID for Verifiable Credential Issuance).
Короткоживучий код в URL і back-channel обмін на JWT поводяться точно так само, як у класичному OAuth; згода встановлюється партнерською угодою, а не діалогом згоди при кожному запуску.
Як виглядає URL переадресації
Що отримує браузер користувача (один рядок у вигляді заголовка Location:):
https://your-app.vergeag.com/launch?code=lc_R3w9q-Kx7VtNm2bH8sLpYj4eQ6gZc1aXfU0dT5nMoP&returnUrl=%2Fpath-planning%2Fboundary%2Fb3f47e1c-8a02-4d59-9c6e-2f7a8b1d6e09
У розшифрованому для читання вигляді:
| Компонент | Значення | Примітки |
|---|---|---|
| Джерело | https://your-app.vergeag.com |
Verge надає продакшн-джерело при підключенні. HTTPS обов'язковий; звичайний HTTP відхиляється. |
| Шлях | /launch |
Публічний маршрут без автентифікації. Попередня сесія Launch Pad не потрібна. |
code |
lc_R3w9q-... |
Префікс lc_ позначає це значення як код запуску (на відміну від API-ключа LP- в логах). Корисне навантаження — 32 байти криптографічно випадкових даних, закодованих у base64url. Одноразовий, TTL 10 хвилин, при видачі прив'язаний до одного користувача, однієї організації та одного returnUrl. |
returnUrl |
/path-planning/boundary/... |
Відносний шлях Launch Pad, на який користувач надсилається після видачі JWT. Використовує сегменти маршруту (наприклад /path-planning/boundary/:id), щоб межа завантажувалась автоматично. Повинен починатися з /. Абсолютні URL, протоколо-відносні URL //host і \ відхиляються при видачі. |
Що робить UI Launch Pad при переході
Ви це не реалізуєте; інформація наведена для довідки, щоб ви розуміли, що відбувається у ваших користувачів між кліком і відображенням поля:
- Читає
codeіreturnUrlз рядка запиту. - Обмінює код з Launch Pad на користувацьку сесію.
- Авторизує користувача в потрібній організації клієнта.
- Видаляє код з адресного рядка, щоб він не залишався в історії браузера.
- Перенаправляє користувача на вказаний вами
returnUrl.
Якщо code відсутній, закінчився або вже використаний, користувач потрапляє на сторінку помилки з проханням повернутися у ваш продукт і спробувати ще раз.
Варіанти повернення детально
Завантажити і вивантажити вручну
Користувач натискає Завантажити в Launch Pad, файл зберігається на його пристрої, і він вивантажує його у ваш продукт через наявний потік імпорту. За замовчуванням для рівня 1. Жодної нової інфраструктури з вашого боку. Вимагає, щоб ваш потік імпорту приймав хоча б один формат, який видає Launch Pad (ISOXML, Shapefile, KML або партнерські формати).
Webhook Push
Launch Pad надсилає HTTPS POST на вказаний вами URL. Кожен запит містить підпис HMAC-SHA256, обчислений за спільним секретом, який Verge видає при підключенні. Ви перевіряєте підпис, обробляєте корисне навантаження і відповідаєте 2xx протягом 10 секунд.
Ключові властивості
- Ви не автентифікуєтесь у Launch Pad для цього потоку. Жодного OAuth-обміну, жодного JWT, жодного API-ключа Launch Pad з вашого боку. Спільний HMAC-секрет — це вся модель автентифікації.
- Один секрет на підписку, з можливістю ротації. Видається один раз при підключенні. Ротація використовує вікно перекриття двох секретів, щоб доставки не переривались при перемиканні.
- Доставка файлу масштабується з розміром корисного навантаження. Невеликі артефакти (менше 1 МБ) передаються вбудовано в base64 всередині тіла webhook. Більші артефакти передаються як короткоживучий підписаний URL завантаження, вбудований у тіло; ви виконуєте GET на цей URL напряму, без облікових даних Launch Pad.
-
Доставка at-least-once. Launch Pad повторює спроби з експоненційним відступом при відповідях не-2xx і таймаутах. Кожна подія містить заголовок
Verge-Webhook-Idдля дедуплікації.
Що ви створюєте
- Публічний HTTPS-ендпоінт, що приймає POST. Жодного входу або сесії не потрібно, крім перевірки підпису.
- Перевірка HMAC зі спільним секретом (близько десяти рядків коду будь-якою мовою).
- Перевірка ідемпотентності за
Verge-Webhook-Id, щоб повторна спроба не оброблялась двічі. - Швидка відповідь 2xx. Обробляйте важку роботу асинхронно, щоб таймаути не викликали шторм повторних спроб.
Що забезпечує Verge
- Вихідний емітер і черга повторних спроб.
- Обробка dead-letter для постійно невдалих доставок.
- Адміністративний інтерфейс для перегляду журналів доставки та відтворення невдалих подій.
- Опублікований список діапазонів вихідних IP, які можна додати до білого списку на брандмауері.
Custom Push (розробка під конкретного партнера)
Якщо у вас вже є автентифікований вхідний API, але ви не хочете створювати універсальний приймач webhook, Verge може написати одноразову push-інтеграцію, яка напряму викликає ваш API. Ви передаєте Verge безпечні облікові дані (бажано API-ключ); емітер Verge автентифікується у вас при кожному push.
Цей варіант існує через асиметрію в напрямку довіри. Для великих FMIS-партнерів (John Deere, Trimble, CNH) кінцеві користувачі автентифікуються в Launch Pad за допомогою облікового запису OEM, тому Launch Pad вже зберігає безпечні токени для відправки даних назад. Launch Pad сьогодні працює за цією моделлю OEM push. При інтеграції рівня 1 напрямок довіри зворотній (ви автентифікуєтесь у Launch Pad), тому у Launch Pad немає попередньо створених облікових даних для вашої системи. Custom Push закриває цю прогалину за допомогою спеціальної угоди.
Компроміси
- Спеціальна розробка з боку Verge. API кожного партнера індивідуальний. Це робота під конкретного партнера, а не універсальна функція, і ціна відображає це.
- Домовленість з довіреним партнером. Ви передаєте Verge API-ключ (або еквівалентні безпечні облікові дані) і управляєте цими обліковими даними зі свого боку.
- Спільне супроводження. Обидві сторони підтримують роботу інтеграції при змінах API та ротації облікових даних.
Підходить, якщо у вас є вхідний API, ви не хочете створювати універсальний приймач webhook і готові фінансувати роботу під конкретного партнера.
Polling Pull (використовувати економно; push переважніший)
Якщо жоден push-варіант не застосовний, ваш бекенд може періодично викликати API Launch Pad (використовуючи той самий X-API-KEY, вже виданий для провізіонування), щоб отримувати плани маршрутів, опубліковані або оновлені з моменту останнього опитування.
Розглядайте це як пакетне отримання з підсумковою узгодженістю, а не як доставку в режимі реального часу. Типова частота — раз на годину або рідше. Високочастотне опитування, що нагадує busy-wait в очікуванні дії користувача, не підтримується і може бути обмежене за частотою. Безперервне опитування протягом годин в очікуванні єдиної користувацької події — це саме той шаблон, для якого цей варіант не призначений.
- Що ви створюєте: цикл опитування з консервативною частотою, дедуплікацією за ID плану маршруту та імпортом до вашого файлового сховища.
- Компроміс: значна затримка між дією користувача та отриманням даних; додаткове навантаження на API Launch Pad.
- Push значно переважніший. Використовуйте опитування лише коли ні Webhook push, ні Custom push неможливі.
Вищі рівні
Ця сторінка — повний довідник з рівня 1. Для вищих рівнів:
Рівень 2 (інтеграція через API)
Публічна схема API доступна на vergeag.com/developers. Коли рівень 1 налаштовано, ви можете розширити інтеграцію, викликаючи більше API напряму, використовуючи той самий API-ключ, що у вас вже є.
Рівень 3 (вбудований інтерфейс)
Зверніться до Verge для оцінки обсягу робіт. Вбудований інтерфейс включає угоди про брендові токени, налаштування iframe-хоста та індивідуальну збірку інтерфейсу для кожного партнера. Самообслуговування недоступне.
Рівень 4 (федерація посвідчень)
Зверніться до Verge для оцінки обсягу робіт. Федерація посвідчень вимагає стандартної реєстрації OIDC-клієнта та угоди про федерацію між обома сторонами.