Monitore o uso da sua chave antes de atingir um limite
Acompanhar seus cabeçalhos de cota ao longo do caminho mostra quando um limite está se aproximando, bem antes de uma requisição ser realmente rejeitada.
Adicione preenchimento automático de endereços a um formulário de checkout
Formulários de checkout falham mais nos campos de endereço do que em qualquer outro campo, geralmente porque o cliente digita errado o nome de uma rua ou esquece o número do apartamento. Sugerir endereços reais enquanto ele digita resolve a maior parte disso antes que vire uma entrega malsucedida.
A requisição de preenchimento automático
O endpoint /v1/autocomplete recebe um texto parcial e um limite de quantas sugestões retornar. Chame-o enquanto o cliente digita, depois que ele tiver inserido alguns caracteres.
GET /v1/autocomplete?q=221B Baker&limit=5{
"status": "ok",
"query": "221B Baker",
"suggestions": [
{"text": "221B Baker Street, London, UK", "place_id": "abc123"},
{"text": "221B Baker Avenue, Springfield", "place_id": "abc124"}
]
}Da sugestão ao endereço completo
Uma sugestão é um rótulo curto e um place_id, não um registro de endereço completo. Depois que o cliente escolher uma, resolva-a para um endereço completo, com componentes e coordenadas, passando o texto da sugestão para /v1/forward. É essa segunda chamada que preenche os campos de rua, cidade, estado e código postal do seu formulário.
GET /v1/forward?q=221B Baker Street, London, UK&limit=1É nessa segunda requisição que o objeto components realmente aparece, já que /v1/autocomplete só retorna um rótulo de texto e um place_id, nunca a divisão em rua, cidade e código postal. Pular esta etapa e tentar interpretar o texto da sugestão por conta própria é mais frágil do que parece, já que a formatação varia de país para país.
Mantendo o número de requisições sob controle
Disparar uma requisição a cada tecla pressionada se acumula rápido em uma página de checkout movimentada. Aplique debounce ao campo para que a requisição só seja enviada depois que o cliente fizer uma breve pausa na digitação, e ignore requisições com menos de três ou quatro caracteres, em que as sugestões não são úteis de qualquer forma. Cada chamada de preenchimento automático e cada chamada de geocodificação direta seguinte contam como uma requisição da sua cota diária, então um campo com debounce em uma loja movimentada ainda pode funcionar bem dentro das 2.500 requisições gratuitas por dia incluídas em cada chave.
Lidando com a ausência de resultados
Um array suggestions vazio é uma resposta normal, não um erro. Deixe o cliente continuar digitando e recorra a um campo de endereço de texto simples se nada útil aparecer depois de alguns caracteres, em vez de bloquear o envio do formulário até que uma sugestão seja escolhida.
Um erro que vale a pena evitar
Tratar uma sugestão clicada como um endereço finalizado e validado é um atalho comum que causa problemas depois. O cliente pode selecionar uma sugestão e continuar editando o campo em seguida, mudando o número da casa ou acrescentando um número de apartamento que a sugestão original não tinha. Sempre resolva o texto final do campo com /v1/forward no momento do envio, e não apenas quando a sugestão foi clicada, para que o endereço salvo reflita o que realmente ficou no campo.
Uma verificação relacionada que vale a pena adicionar
Se o seu formulário de checkout também coleta o código postal separadamente, uma chamada rápida a /v1/postcode assim que o endereço for resolvido é uma forma barata de identificar um código postal que não corresponde ao restante do endereço, antes que os dois sejam enviados juntos e causem uma divergência na entrega mais adiante.
O preenchimento automático não substitui a validação, ele apenas reduz as chances de um endereço ruim chegar ao seu sistema de pedidos. Consulte a documentação de preenchimento automático de endereços para ver a lista completa de parâmetros antes de integrá-lo ao seu fluxo de checkout.