Um comprador que preenche automaticamente um formulário de checkout a partir de um registro salvo no navegador, ou que copia um endereço de um e-mail antigo, às vezes acaba com o código postal de um lugar combinado com o nome da cidade de outro, um erro fácil de cometer e fácil de deixar passar ao conferir rapidamente um formulário preenchido antes de clicar em enviar. Uma loja online que enviava produtos físicos descobriu exatamente essa divergência por trás de um fluxo constante e discreto de entregas extraviadas ou atrasadas, cada uma pequena por si só e, somadas, um custo real em reenvios e frustração dos clientes.
A solução foi uma verificação cruzada executada automaticamente no checkout, antes da confirmação do pedido. O código postal informado no formulário ia para /v1/postcode, que resolve a que local esse código realmente corresponde. A loja comparava o local resolvido com a cidade e a região que o comprador também tinha informado no mesmo formulário e, quando claramente divergiam, em vez de deixar o pedido passar e descobrir a divergência só quando uma entrega fosse para o lugar errado, o fluxo de checkout pausava com um aviso simples pedindo que o comprador conferisse o código postal e a cidade antes de continuar.
A loja também passava o endereço completo informado por /v1/forward como uma segunda camada, já que um endereço pode passar na verificação cruzada entre código postal e cidade e ainda ter um problema real em outro ponto, uma rua que não existe com aquele nome ou um número fora da faixa plausível para aquela rua, e a confiança da correspondência retornada pela chamada de geocodificação direta dava ao fluxo de checkout um segundo sinal a ser considerado junto com a comparação do código postal, sinalizando correspondências claramente fracas para o mesmo aviso rápido de confirmação.
A loja foi criteriosa sobre quanto atrito isso adicionava. A maioria dos pedidos passava nas duas verificações instantaneamente e seguia pelo checkout sem nenhuma mudança visível, já que a grande maioria dos compradores informa o próprio endereço corretamente na primeira vez. Apenas o número menor de pedidos com uma divergência real via o aviso de confirmação e, mesmo assim, o comprador levava só alguns segundos para revisar e corrigir, ou confirmar que o endereço estava de fato correto como informado, já que um endereço legitimamente incomum ainda podia acionar a verificação sem estar errado.
Esse tipo de verificação se paga justamente porque o custo de detectar uma divergência antes do envio é muito menor do que o custo de um pedido que já foi enviado para o lugar errado: um reenvio, mais uma entrega original atrasada ou perdida, mais, muitas vezes, um cliente frustrado que agora tem menos chance de comprar de novo. Corrigir isso nos poucos segundos antes de o pedido ser feito, em vez dos dias necessários para descobrir e corrigir um problema de envio depois do fato, levou esse custo de significativo para quase nada.
Cada pedido acionava uma verificação de código postal e uma verificação de endereço, uma carga de trabalho que crescia diretamente com o volume de vendas e ficava dentro da cota diária gratuita para uma loja de porte moderado na maior parte do ano, com crédito pré-pago cobrindo os períodos mais movimentados sem exigir nenhum planejamento especial com antecedência.
A documentação dos dois endpoints está em /docs/postal-code-lookup/ e /docs/forward-geocoding/, e o comportamento geral de tratamento de erros de ambos é explicado em /docs/errors/.