EN PT-BR
Integrações de Parceiros do Launch Pad
Para Plataformas Agrícolas e Parceiros FMIS

Adicione Planejamento de Trajetos à Sua Plataforma

O Launch Pad é a plataforma de agricultura de precisão da Verge Ag: planejamento de trajetos, otimização de rotas e operações de campo. Parceiros incorporam ao próprio produto por meio de uma API REST e uma UI white-label básica, sem precisar construir ou operar os sistemas subjacentes.

Ver Níveis de Integração

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.

4
Níveis de Integração
2/5
Esforço do Nível 1
REST
Estilo de API
OAuth 2.0
Padrão de Auth
Recurso Complementar

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 Desenvolvedor

O 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.

A Maioria dos Parceiros Começa Aqui

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.

Detalhes do Nível 1

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:

  1. Configuração de conta (cadastro, login, seleção de empresa). Seu backend cria e autentica o usuário nos bastidores.
  2. 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.

Padrão do Nível 1

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.

Recomendado para Produção

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.

Engenharia Por Parceiro

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.

Use com Parcimônia

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.

Para Desenvolvedores

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:

  1. code e returnUrl da query string.
  2. Troca o código com o Launch Pad por uma sessão de usuário.
  3. Autentica o usuário na organização de cliente correta.
  4. Remove o código da barra de endereço para que ele não fique no histórico do navegador.
  5. Envia o usuário para o returnUrl que 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-Id para 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-Id para 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.

Vamos Conversar Sobre uma Integração de Parceiro

Integrações de parceiros são escopadas caso a caso. Entre em contato e vamos detalhar juntos a escolha do nível, as opções de devolução e o onboarding.

Falar com a Verge Ag