Visão Geral
A integração de parceiros do Launch Pad permite que sua plataforma incorpore planejamento de trajetos, otimização de rotas e operações de campo sem precisar construir ou operar os sistemas subjacentes. Quatro níveis de integração variam de um simples deep link até federação completa de identidade, todos baseados em uma API REST pública e autenticação OAuth 2.0 padronizada.
Cada nível funciona por conta própria. A maioria dos parceiros começa no Nível 1 (Lançamento em Um Clique) e adiciona níveis superiores depois, conforme as necessidades mudam. As seções abaixo descrevem o que seus usuários finais experimentam, o que você ganha como empresa, o detalhamento completo dos quatro níveis e um aprofundamento no Nível 1. A seção Detalhes Técnicos mais adiante contém a especificação de engenharia.
Portal do Desenvolvedor & Referência da API
Referência completa da API REST, padrões de autenticação e guias de primeiros passos para a API pública do Launch Pad. Consulte este recurso quando começar a escopar qualquer nível acima do Nível 1, ou sempre que precisar de detalhes no nível de endpoint além do que esta página cobre.
Acessar o Portal do DesenvolvedorO Que Seus Usuários Experimentam
No Nível 1, o Launch Pad funciona como um aplicativo complementar ao seu produto. Ele abre em uma nova janela do navegador com toda a preparação feita em segundo plano, para que o usuário possa começar a trabalhar imediatamente.
Sem Novo Cadastro
Os usuários não criam uma conta no Launch Pad. A identidade deles vem do seu produto.
Sem Segundo Login
Os usuários são autenticados automaticamente quando abrem o Launch Pad a partir do seu aplicativo.
Sem Upload de Arquivos Para Começar
O talhão certo e seu contorno já estão carregados quando o usuário chega. A manipulação de talhões é um dos maiores obstáculos quando produtores adotam ferramentas agrícolas externas; um fluxo "hyperlink, fazer login, subir arquivo" desperdiça a maior parte do valor que uma integração deveria entregar.
Viagem de Volta (Manual no Começo)
Quando os usuários terminam, baixam o arquivo do plano de trajeto do Launch Pad e fazem upload no seu produto. Um lugar natural para automatizar mais tarde via Webhook push ou uma integração de Custom push, reaproveitando o cliente de API que você já construiu para o Nível 1.
O Que Você Ganha Como Parceiro
Feito para empresas e equipes de engenharia que querem incorporar roteirização de precisão sem precisar montar a infraestrutura que a sustenta.
Uma Identidade de Administrador
Um único usuário administrador é sua identidade dentro do Launch Pad. Esse mesmo usuário detém a API key para chamadas servidor-a-servidor e também pode entrar diretamente no Launch Pad para inspecionar, auditar ou dar suporte a um cliente.
Faturamento Consolidado
Todo o uso é consolidado em uma única conta de faturamento do parceiro. Usuários finais nunca veem saldos de créditos ou faturas dentro do Launch Pad. Você é a parte cobrada; o preço é por volume e negociado.
Visão de Admin Entre Clientes
Seu admin vê uso, planos, talhões e atividade por usuário de cada cliente que você cadastra, tudo em um só lugar. Essa é a visibilidade que você precisa para dar suporte aos clientes e reconciliar o faturamento.
Quatro Níveis de Integração
Cada nível funciona por conta própria. A maioria dos parceiros começa no Nível 1 e adiciona níveis superiores depois, conforme as necessidades mudam.
Nível 1: Lançamento em Um Clique
Os usuários abrem o Launch Pad a partir do seu produto sem precisar se cadastrar, fazer login ou subir um talhão. O talhão certo já aparece na tela. O arquivo do plano de trajeto finalizado retorna ao seu produto pelo seu fluxo atual de importação de arquivos.
Você constrói: chamadas de API para criar o usuário, solicitar um link de lançamento, enviar o talhão e redirecionar o navegador. Seu fluxo atual de importação de arquivos aceita o arquivo retornado.
Nível 2: Integração via API
Acesso programático completo a empresas, produtores, fazendas, talhões, contornos, planos de trajeto e rotas por meio de uma API REST. Notificações de eventos em ações-chave.
Você constrói: uma camada de sincronização entre seu produto e o Launch Pad. Um receptor de webhook (preferido) ou polling agendado para o caminho de volta.
Nível 3: UI Embutida
Telas do Launch Pad exibidas dentro do seu produto, em um iframe. Navegação oculta, com as cores da sua marca.
Você constrói: um host de iframe. Um pequeno handshake para passar as cores da sua marca.
Nível 4: Federação de Identidade
"Entrar com o Launch Pad" (ou o inverso) usando OpenID Connect padronizado. O consentimento do usuário final e a vinculação de contas são gerenciados pelo Launch Pad.
Você constrói: uma biblioteca cliente OpenID Connect e um armazenamento de tokens.
Como o Nível 1 Elimina a Fricção
Por Que o Nível 1 Existe
O Nível 1 é a diferença entre uma integração e um hyperlink. Da perspectiva do usuário, o Planejamento de Trajetos é parte do seu produto: ele clica em um botão, executa a tarefa e leva o resultado de volta.
Para que isso funcione, o Nível 1 elimina os dois momentos de maior fricção na adoção de uma ferramenta agrícola externa:
- Configuração de conta (cadastro, login, seleção de empresa). Seu backend cria e autentica o usuário nos bastidores.
- Upload de talhão. Seu backend envia o talhão para o Launch Pad pela API antes de abrir a janela, então o usuário chega com o talhão certo já na tela.
O manuseio de talhões é o mais impactante dos dois. É um dos maiores obstáculos quando produtores adotam ferramentas agrícolas externas.
Modelo de Conta
Um engajamento de Nível 1 é organizado assim:
Sua identidade no Launch Pad é um único usuário administrador
Esse usuário detém sua API key, tem visibilidade administrativa em todas as organizações de cliente que você criar e também pode entrar diretamente no Launch Pad para inspecionar, auditar ou dar suporte a um cliente. Os usuários finais nunca veem esse usuário.
Cada cliente se torna sua própria organização dentro do Launch Pad
Povoada com os usuários finais que você cria. Um usuário final só enxerga a própria organização; nunca vê os dados de clientes de outros parceiros.
O faturamento é consolidado na sua conta de cobrança
Usuários finais nunca veem saldos de créditos ou faturas dentro do Launch Pad; você é a parte cobrada.
Visão de admin entre clientes
Seu usuário administrador vê uso por organização de cliente, contagens de planos e talhões e atividade por usuário de cada cliente em um só lugar. Essa é a visibilidade que você precisa para dar suporte aos clientes e reconciliar o faturamento.
O Que os Usuários Veem no Launch Pad
Quando um usuário abre o Launch Pad pelo Nível 1, algumas opções do Launch Pad não se aplicam e ficam ocultas:
- Sem troca de senha, sem gerenciamento de e-mail ou conta, sem cadastro. O usuário não tem senha do Launch Pad; o login vem do seu produto. A tela de troca de senha mostra uma mensagem "Senha gerenciada pelo [Parceiro]", igual à forma como o Launch Pad já lida com usuários que entram via John Deere, Trimble ou CNH.
- Sem seletor de empresa. A sessão fica travada em uma única organização de cliente para aquela visita.
- Logout é substituído por "Voltar para [Parceiro]", que fecha a aba ou envia o usuário de volta a uma URL que você fornece, em vez de deixá-lo na tela de login do Launch Pad.
O menu principal de trabalho (Planos, Planejamento de Trajetos, Equipamentos, Comparar) continua disponível porque os usuários precisam dele para fazer a tarefa. Só ficam ocultas as opções de identidade, faturamento, administração e gestão de conta.
Devolução do Plano de Trajeto
Depois que um usuário finaliza um plano de trajeto no Launch Pad, o resultado precisa voltar para o seu produto. Quatro opções estão disponíveis e funcionam em cima de qualquer nível. Opções de push são fortemente preferíveis a polling.
Download / Upload Manual
O usuário clica em Baixar no Launch Pad e depois faz upload do arquivo no seu produto.
Melhor quando: for o caminho mais rápido para começar.
Webhook Push
O Launch Pad envia cada plano finalizado para uma URL que você fornece, assinado com HMAC.
Melhor quando: você quer entrega em tempo real e pode hospedar um endpoint genérico de webhook.
Custom Push
A Verge escreve uma integração sob medida que entrega os planos finalizados diretamente na sua API existente.
Melhor quando: você tem uma API de entrada que aceita credenciais, mas não quer construir um receptor de webhook.
Polling Pull
Seu backend busca periodicamente os planos finalizados na API do Launch Pad.
Melhor quando: nenhuma opção de push é viável. A cadência precisa ser conservadora.
Pré-requisito obrigatório para Download/upload manual: seu fluxo de importação precisa aceitar pelo menos um formato que o Launch Pad emite (ISOXML, Shapefile, KML ou formatos específicos do parceiro; confirmado durante o escopo). Sem essa sobreposição, o Nível 1 não consegue entregar um fluxo ponta a ponta utilizável.
Detalhes Técnicos
Quem não é técnico pode parar por aqui. O restante desta página é a especificação de engenharia: fluxo ponta a ponta, anatomia da URL de redirecionamento e mecânica da devolução.
Fluxo Ponta a Ponta
O que acontece, passo a passo, quando um usuário do parceiro abre o Launch Pad:
sequenceDiagram
autonumber
participant YU as UI do Parceiro
participant YB as Backend do Parceiro
participant LA as Launch Pad API
participant LU as Launch Pad UI
YU->>YB: usuário clica em "Abrir Plano de Trajeto"
note over YB,LA: Etapa 1: criar usuário do LP se não existir
YB->>LA: POST /api/users (idempotente em externalUserId)
YB->>LA: POST /api/company-accesses (idempotente em usuário + org)
note over YB,LA: Etapa 2 (opcional): enviar um talhão
YB->>LA: POST /api/vBoundary/upsert
note over YB,LA: Etapa 3: solicitar um código de lançamento
YB->>LA: POST /api/partner/launch ({ userId, companyId, returnUrl })
LA-->>YB: { code, expiresInSec: 600 }
YB-->>YU: 302 redireciona para https://your-app.vergeag.com/launch?code=...
YU->>LU: navegador navega para /launch?code=...
LU->>LA: POST /api/partner/launch/{code}/exchange
LA-->>LU: JWT + refresh token
note over LU: armazena JWT no localStorage,
remove o código da URL,
navega para returnUrl
Propriedades Principais
- Você autentica servidor-a-servidor com uma credencial de longa duração (a API key do seu usuário administrador). O navegador nunca vê a API key.
- O navegador só vê um código opaco, de uso único e curta duração na URL (time-to-live de 10 minutos, consumido na troca).
- O endpoint de troca não exige login; o próprio código é a credencial. A UI do Launch Pad o chama assim que o usuário chega.
- O Launch Pad emite uma sessão de usuário normal (JWT + refresh token), armazena no localStorage e direciona o usuário para a URL que você especificou.
Alinhamento com Padrões
O padrão é o OAuth 2.0 Authorization Code Grant, com a tela interativa de consentimento substituída por uma chamada de autorização servidor-a-servidor do seu backend. A terminologia moderna do OAuth chama essa variante de back-channel de Pre-Authorized Code Flow (introduzido na spec OpenID for Verifiable Credential Issuance).
O código de curta duração na URL e a troca por um JWT pelo canal de fundo se comportam exatamente como no OAuth de livro-texto; o consentimento é estabelecido pelo acordo de parceria em vez de um diálogo de consentimento por lançamento.
Como É a URL de Redirecionamento
O que o navegador do usuário recebe (uma linha, como cabeçalho Location:):
https://your-app.vergeag.com/launch?code=lc_R3w9q-Kx7VtNm2bH8sLpYj4eQ6gZc1aXfU0dT5nMoP&returnUrl=%2Fpath-planning%2Fboundary%2Fb3f47e1c-8a02-4d59-9c6e-2f7a8b1d6e09
Decodificada para leitura:
| Componente | Valor | Notas |
|---|---|---|
| Origem | https://your-app.vergeag.com |
A Verge fornece a origem de produção durante o onboarding. HTTPS é obrigatório; HTTP puro é recusado. |
| Caminho | /launch |
Rota pública e não autenticada. Nenhuma sessão prévia do Launch Pad é necessária. |
code |
lc_R3w9q-... |
O prefixo lc_ marca esse valor como código de lançamento (distinto de uma API key LP- nos logs). O payload é de 32 bytes aleatórios criptográficos, codificado em base64url. Uso único, TTL de 10 minutos, vinculado no momento da emissão a um usuário, uma org e um returnUrl. |
returnUrl |
/path-planning/boundary/... |
O caminho relativo do Launch Pad para onde o usuário é enviado depois que o JWT é emitido. Usa segmentos de rota (ex.: /path-planning/boundary/:id) para que o talhão carregue automaticamente. Precisa começar com /. URLs absolutas, URLs relativas a protocolo //host e \ são rejeitadas na emissão. |
O Que a UI do Launch Pad Faz ao Chegar
Você não implementa isso; está aqui só como referência para você raciocinar sobre o que seus usuários veem entre o clique e o talhão renderizado:
- Lê
codeereturnUrlda query string. - Troca o código com o Launch Pad por uma sessão de usuário.
- Autentica o usuário na organização de cliente correta.
- Remove o código da barra de endereço para que ele não fique no histórico do navegador.
- Envia o usuário para o
returnUrlque você especificou.
Se code estiver ausente, expirado ou já consumido, o usuário vai parar em uma página de erro que pede para voltar ao seu produto e tentar de novo.
Opções de Devolução em Detalhe
Download / Upload Manual
O usuário clica em Baixar no Launch Pad, o arquivo vai parar no dispositivo dele e ele faz upload no seu produto pelo seu fluxo atual de importação de arquivos. Padrão do Nível 1. Sem infraestrutura nova do seu lado. Requer que seu fluxo de importação aceite pelo menos um formato que o Launch Pad emite (ISOXML, Shapefile, KML ou formatos específicos do parceiro).
Webhook Push
O Launch Pad envia POSTs HTTPS para uma URL que você fornece. Cada requisição carrega uma assinatura HMAC-SHA256, calculada contra um segredo compartilhado que a Verge emite no onboarding. Você verifica a assinatura, processa o payload e responde com 2xx em até 10 segundos.
Propriedades Principais
- Você não se autentica no Launch Pad para esse fluxo. Sem handshake OAuth, sem JWT, sem API key do Launch Pad do seu lado. O segredo HMAC compartilhado é todo o modelo de autenticação.
- Um segredo por assinatura, rotacionável. Emitido uma vez no onboarding. A rotação usa uma janela de sobreposição entre dois segredos, para que as entregas não falhem durante o cutover.
- A entrega de arquivo escala com o tamanho do payload. Artefatos pequenos (menos de 1 MB) vão inline em base64 dentro do corpo do webhook. Artefatos maiores vão como uma URL presigned de download de curta duração embutida no corpo; você faz GET nessa URL diretamente, sem credenciais do Launch Pad.
-
Entrega at-least-once. O Launch Pad faz retry com backoff exponencial em respostas não-2xx e timeouts. Cada evento carrega um cabeçalho
Verge-Webhook-Idpara que você possa fazer deduplicação.
O Que Você Constrói
- Um endpoint HTTPS público que aceita POSTs. Nenhum login ou sessão é exigida no endpoint além da verificação da assinatura.
- Verificação HMAC com o segredo compartilhado (cerca de dez linhas de código em qualquer linguagem).
- Um teste de idempotência no
Verge-Webhook-Idpara que um retry nunca processe duas vezes. - Uma resposta 2xx rápida. Processe qualquer trabalho pesado de forma assíncrona para que timeouts não disparem chuvas de retry.
O Que a Verge Opera
- O emissor de saída e a fila de retry.
- Tratamento de dead-letter para entregas permanentemente falhadas.
- Uma UI administrativa onde você consulta logs de entrega e reaplica eventos que falharam.
- Uma lista publicada de faixas de IP de saída que você pode liberar no firewall.
Custom Push (engenharia por parceiro)
Se você já tem uma API de entrada autenticada, mas não quer construir um receptor genérico de webhook, a Verge pode escrever uma integração de push sob medida que chama a sua API diretamente. Você compartilha credenciais seguras com a Verge (preferencialmente uma API key); o emissor da Verge se autentica em você a cada push.
Essa opção existe por causa de uma assimetria no sentido da confiança. Para grandes parceiros FMIS (John Deere, Trimble, CNH), os usuários finais se autenticam no Launch Pad com a conta do OEM, então o Launch Pad já mantém tokens seguros para devolver dados. O Launch Pad já opera esse modelo de OEM push hoje. Numa integração de Nível 1, o sentido da confiança é invertido (você se autentica no Launch Pad), então o Launch Pad não tem nenhuma credencial pré-existente para o seu sistema. O Custom push fecha essa lacuna com um arranjo sob medida.
Trade-offs
- Engenharia sob medida do lado da Verge. A API de cada parceiro é diferente. É trabalho por parceiro, não um recurso genérico, e o preço reflete isso.
- Arranjo de parceiro de confiança. Você compartilha uma API key (ou credencial segura equivalente) com a Verge e opera essa credencial do seu lado.
- Manutenção conjunta. Os dois lados mantêm a integração funcionando através de mudanças de API e rotações de credenciais.
Adequado quando você já tem uma API de entrada, não quer construir um receptor genérico de webhook e está comprometido o suficiente para bancar o trabalho por parceiro.
Polling Pull (use com parcimônia; push é preferido)
Se nenhuma opção de push for viável, seu backend pode chamar periodicamente a API do Launch Pad (usando a mesma X-API-KEY já emitida para provisionamento) para buscar planos de trajeto publicados ou atualizados desde a última consulta.
Trate isso como recuperação em lote eventualmente consistente, não como entrega em tempo real. Uma cadência típica é horária ou menos frequente. Polling de alta frequência que pareça um busy-wait contra uma ação do usuário não é suportado e pode sofrer rate limit. Ficar fazendo polling por horas esperando um único evento iniciado pelo usuário é exatamente o padrão que essa opção não atende.
- O que você constrói: um loop de polling com cadência conservadora, deduplicação por ID de plano de trajeto e ingestão no seu armazenamento de arquivos.
- Trade-off: latência significativa entre a ação do usuário e a chegada do dado; carga adicional sobre a API do Launch Pad.
- Push é fortemente preferido. Use polling apenas quando nem Webhook push nem Custom push forem viáveis.
Níveis Superiores
Esta página é a referência completa para o Nível 1. Para níveis superiores:
Nível 2 (Integração via API)
O schema público da API está em vergeag.com/developers. Com o Nível 1 no lugar, você pode expandir a integração chamando mais da API diretamente, com a mesma API key que você já possui.
Nível 3 (UI Embutida)
Fale com a Verge para escopar. UI Embutida envolve acordos de brand tokens, configuração de host de iframe e um build da UI por parceiro. Não é self-service.
Nível 4 (Federação de Identidade)
Fale com a Verge para escopar. Federação de Identidade exige registro de cliente OIDC padronizado e um acordo de federação entre os dois lados.