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 um relógio de horário local a um painel de suporte
Um agente de suporte que está decidindo se liga para um cliente agora se beneficia de saber que horas realmente são onde esse cliente está, e não que horas são no escritório.
Obtendo o fuso horário do cliente
Se você já tem um endereço de entrega ou de cobrança cadastrado, faça a geocodificação dele uma vez para obter as coordenadas e depois passe essas coordenadas para /v1/timezone. Se tudo o que você tem é o endereço IP da última visita, o endpoint /v1/ip retorna um campo timezone diretamente, sem uma consulta separada.
GET /v1/timezone?lat=35.6762&lon=139.6503{
"status": "ok",
"timezone": "Asia/Tokyo",
"utc_offset": "+09:00",
"abbreviation": "JST"
}Quando não há endereço nem IP cadastrado
Para um lead ou um chamado sem endereço e sem IP registrado, não existe uma coordenada confiável a partir da qual consultar um fuso horário, e adivinhar com base no código de país de um telefone ou em uma configuração de idioma não é algo que este endpoint possa fazer por você. Nesse caso, peça diretamente um fuso horário ou uma localização aproximada, em vez de exibir um relógio construído a partir de um palpite que tem chance real de errar por várias horas.
Exibindo o relógio
Armazene o identificador de fuso horário no registro do cliente e calcule o horário local atual a partir dele sempre que o painel for exibido, em vez de armazenar um deslocamento fixo que ficará desatualizado nas mudanças de horário de verão. Como o site não tem JavaScript no lado do cliente, gere o horário local atual no servidor ao carregar a página e atualize-o a cada requisição de página, em vez de fazê-lo avançar ao vivo no navegador.
Uma consulta por cliente, não por visualização de página
O identificador de fuso horário da localização de um cliente não muda de um dia para o outro, então consulte-o uma vez quando o endereço ou o IP for registrado pela primeira vez e armazene o identificador, em vez de chamar a API toda vez que o painel carregar. Isso mantém este recurso em um punhado de requisições no total, e não uma por visualização de página, o que importa se o painel é aberto muitas vezes por dia por uma equipe de suporte.
Um erro que vale a pena evitar
Recalcular o deslocamento de uma interação de suporte passada usando a consulta de fuso horário de hoje, em vez do timestamp da própria interação, pode mostrar a hora errada perto de uma mudança de horário de verão. Se um painel precisa mostrar que horas eram para o cliente no momento em que um chamado antigo foi aberto, passe o timestamp desse chamado pelo parâmetro time em vez de depender do deslocamento atual.
Quanto custa
Mesmo sem armazenar o identificador em cache, cada consulta é uma única requisição, então uma equipe de suporte de qualquer tamanho razoável cabe folgadamente nas 2.500 requisições gratuitas por dia incluídas em cada chave, ou na mesma cota a partir de um único endereço sem chave.
Mantendo tudo atualizado
Se o endereço cadastrado de um cliente mudar, atualize o identificador de fuso horário armazenado ao mesmo tempo, em vez de deixar um identificador desatualizado preso ao registro indefinidamente. Um cliente que se mudou e continua com o identificador de fuso horário antigo verá o horário local errado até o registro ser atualizado, sem nenhum aviso, já que nada na consulta antiga falha ou gera erro por conta própria.
Um relógio de horário local ao lado de um chamado é um pequeno acréscimo que poupa o agente de suporte de fazer contas de fuso horário de cabeça antes de cada ligação. A documentação da consulta de fuso horário descreve a requisição por completo.