Há algum tempo, embarquei em uma busca para descobrir se existia um padrão unificado de API/EDI de transporte que fosse utilizado por várias empresas de logística. Certamente, nos dias de hoje, algo assim deve existir, certo? Um formato universal de API de envio?

Bem, para resumir, isso não existe.

O mais próximo que você pode chegar é algum provedor de API que tenha construído muitas conexões de API de transportadoras e então ofereça seu próprio endpoint de API para acessar diferentes provedores de serviços de transporte.

Neste artigo, vou abordar algumas APIs de transportadoras diferentes, descrever brevemente suas capacidades e discutir maneiras de implementá-las.

NB! Se você está apenas procurando por um protocolo universal de API de transporte, aqui está um link onde você pode agendar uma rápida chamada comigo.

De qualquer forma, vamos começar com um...

Primeiro, vamos definir o objetivo.

Considere um fabricante médio com clientes e fornecedores nacionais e internacionais. As mercadorias precisam ser coletadas dos fornecedores e entregues no local de produção, enquanto os produtos finais precisam ser enviados aos clientes.

Para estabelecer uma cadeia de suprimentos confiável, seu típico fabricante de médio porte precisaria de 10-20 parceiros de transporte:

Gerenciar todos esses relacionamentos já é complexo o suficiente. Mas a verdadeira diversão começa quando você tenta integrar seus sistemas de TI! (já que não existe um protocolo unificado de API de frete)

Em segundo lugar, precisamos concordar sobre o escopo.

Nem todas as empresas de logística oferecem o mesmo nível de serviço. Algumas têm APIs muito sofisticadas fornecendo preços de frete instantâneos, reservas, etiquetas, rastreamento, solicitações de correio, etc., enquanto outras podem ter apenas um portal onde você pode fazer login e enviar uma reserva. Algumas não têm sistemas de TI - apenas e-mail. Para nosso cenário alvo, vamos manter as coisas simples e apenas visar:

Parece simples o suficiente, certo? Ah, se fosse só isso...

A maneira manual de lidar com as coisas, que parece ser o padrão da indústria para a maioria das empresas, envolve o uso de portais de transportadoras sempre que possível e comunicação via e-mail com o restante dos parceiros de transporte. Em nosso exemplo, assumimos que as listas de preços de transporte, horários, prazos de entrega e tratamento de faturas são gerenciados separadamente. Para envios de reservas, nosso objetivo é construir uma conexão de API do nosso sistema ERP.

Vamos supor que selecionamos a seguinte lista de empresas de transporte e precisamos construir uma conexão direta de API para seus sistemas a partir do nosso software ERP. Esta seleção é aleatória e cobre apenas uma fração das diferentes APIs de transportadoras existentes.

DHL Express – usa um portal chamado MyDHL, que também tem capacidades de API. No entanto, usa APIs diferentes para os ramos de Frete, Express e Global Forwarding, e abordagens de API diferentes em várias regiões. O acesso ao serviço web requer um protocolo SOAP, Serviços RESTful ou XML simples, e os desenvolvedores devem estar familiarizados com XML/JSON e ter um entendimento básico de serviços web. A especificação da API sozinha tem 457 páginas. É minuciosa, mas seu desenvolvedor cobrará pelas horas gastas apenas lendo-a. Uma vez implementada, você precisaria acionar uma média de 5-12 solicitações por envio, começando pela autenticação até validações de endereço, verificações de disponibilidade e solicitações de etiquetas.

Schenker – usa diferentes soluções de API/EDI em várias regiões. Mais comumente, usa um protocolo SOAP com formato XML. A mensagem em si é direta, desde que todos os possíveis erros sejam tratados adequadamente. Os desenvolvedores precisam de acesso personalizado para implementar a API. Dependendo da sua localização, você pode ser solicitado a implementar uma solução EDIFACT em vez disso, que abordarei mais tarde.

DSV – recentemente mudou para seu portal com capacidade de API chamado MyDSV. Dado que a API é bastante nova, ela aproveita algumas das abordagens mais recentes e modernas no mundo das APIs. Apesar da complexidade ao autenticar e navegar em seu catálogo de produtos, a abordagem é direta. Novamente, dependendo da sua localização, o EDIFACT pode ser preferido.

FedEx e TNT – isso pode ser divertido. Primeiro, você precisa determinar se está usando os serviços da TNT ou da FedEx. Embora devessem ser a mesma empresa há vários anos, a migração ainda está pendente. Se seu contrato é com a TNT, provavelmente você será solicitado a implementar a API TNT Express Connect. A implementação em si é de complexidade média. A desvantagem é que esta API é considerada obsoleta e será desativada eventualmente. A API da FedEx, por outro lado, é mais complexa e oferece várias opções dependendo da região em que você está baseado. Na Cargoson, implementamos a API FedEx Compatible, que fornece algumas funcionalidades adicionais muito interessantes, mas está disponível apenas para parceiros FedEx Compatible.

UPS – usa uma API baseada em JSON e OAuth para autenticação, o que significa que há várias solicitações que você teria que acionar antes de conseguir sua reserva e receber as etiquetas de volta.

Em seguida, temos o EDIFACT, usado por muitas empresas de transporte como DSV, Maersk, DB Schenker, Kuehne + Nagel, C.H. Robinson, CEVA Logistics, etc. É um padrão muito antigo, e mesmo que possa parecer que você poderia se livrar com uma integração de API para várias empresas de logística, pense novamente. A maior desvantagem é que é uma conexão baseada em troca de arquivos, o que significa que você teria que gerar um arquivo físico real, depois transmiti-lo via FTP e literalmente esperar que tudo esteja bem porque há um feedback muito complicado sobre erros e avisos.

Semelhante ao EDIFACT é o FORTRAS, uma conexão baseada em arquivos com as mesmas deficiências. É mais utilizado na Alemanha e países vizinhos. Não só a troca de arquivos é desafiadora, mas o formato do arquivo em si é difícil de ler e, portanto, muito demorado para depurar erros. Algumas empresas bem conhecidas que o utilizam incluem Dachser, Schenker, Kuehne + Nagel, Hellmann Worldwide Logistics, GLS, Hermes, Gebrüder Weiss, etc.

Mesmo após implementar todas as integrações mencionadas acima, a questão permanece:

O que você faz com empresas transportadoras que não possuem nenhum sistema de TI ou portal, muito menos uma API para aceitar pedidos de transporte?

A solução mais simples é enviar um simples e-mail. Embora isso possa parecer direto, vamos aprofundar. Configurar a conexão técnica com seu servidor de e-mail é uma coisa, mas e quanto aos contatos? Normalmente, diferentes direções são tratadas por diferentes pessoas de contato, e as pessoas mudam de posição. Assim, você precisaria construir uma matriz de contatos bastante abrangente em seu ERP.

Então, quais são as alternativas para lidar com APIs de transportadoras díspares e protocolos EDI?

Uma opção a considerar é uma API multi-transportadora. Essencialmente, este é um provedor de serviços que construiu todas as conexões de transportadoras, sejam APIs modernas, protocolos EDI antigos baseados em EDIFACT ou FORTRAS ou integrações de e-mail, e as disponibilizou através de sua própria API de envio padronizada. Em vez de implementar várias APIs de transportadoras e mantê-las atualizadas, você pode implementar apenas um padrão de API multi-transportadora e acionar todos os seus pedidos de transporte através dele.

Mas nós fomos ainda mais longe.

Diferentes empresas de logística oferecem níveis variados de serviço. Algumas fornecem uma API de reserva, enquanto outras não; algumas oferecem capacidades de rastreamento, enquanto outras carecem desse recurso. Na Cargoson, implementamos todos os recursos que preenchem as lacunas para cada empresa de transporte.

Por exemplo, quando uma transportadora não oferece reserva online, fornecemos um portal para isso. Se eles não têm rastreamento, nós adicionamos. Temos sistemas para upload de prova de entrega (POD) e outros documentos, API multi-transportadora completa, estimativas de ETA, cálculos de preço de transporte, estatísticas de desempenho e até mesmo números de emissão de CO2 do transporte. Basicamente, o que quer que uma transportadora não tenha, nós construímos para que você não precise se preocupar com diferenças de nível de TI ou serviço entre suas transportadoras.

Veja como a Cargoson melhora suas transportadoras existentes

Aqui está um exemplo do mundo real: Grandes players como FedEx, TNT e DHL Express oferecem uma API de preços. Isso significa que quando você aciona uma solicitação de preço da Cargoson, os preços são obtidos diretamente do sistema da transportadora. No entanto, em casos onde uma empresa como a DSV não fornece uma API de preços, a lista de preços em Excel ou PDF fornecida pela DSV é carregada na Cargoson, e o cálculo de preço é realizado dentro do nosso sistema. Temos um poderoso mecanismo de upload e cálculo de preços de frete para isso. A mesma abordagem pode ser aplicada a todas as outras empresas de transporte e também é aplicável a outros recursos.

Nosso objetivo é simples: dar a você uma experiência consistente e de alta qualidade em todas as transportadoras, mesmo que nem todas comecem com as mesmas capacidades. Um padrão de facto de API universal de transportadora e plataforma multi-transportadora em um só.

Se você está procurando uma maneira melhor de gerenciar suas integrações de transportadoras, a Cargoson pode ajudar. Nossa plataforma fornece uma única API de transporte padronizada que conecta você a todas as suas transportadoras, independentemente de suas capacidades individuais. Isso significa que você pode acessar todos os seus serviços de envio através de uma interface unificada, sem se preocupar com as diferenças técnicas subjacentes.

Quer ver como isso poderia funcionar para o seu negócio? Vamos fazer uma rápida chamada para discutir sua configuração atual e desafios específicos de integração. Podemos analisar alguns exemplos do mundo real de como a Cargoson ajudou empresas em casos semelhantes ao seu:

Agende uma consulta gratuita de 30 minutos