Controla el uso de tu clave antes de alcanzar un límite
Vigilar las cabeceras de cuota sobre la marcha te indica cuándo te acercas a un límite, mucho antes de que se rechace realmente una solicitud.
Añade un reloj de hora local a un panel de soporte
A un agente de soporte que decide si llamar a un cliente ahora mismo le sirve saber qué hora es realmente donde está ese cliente, no qué hora es en la oficina.
Obtener la zona horaria del cliente
Si ya tienes registrada una dirección de envío o de facturación, geocodifícala una vez para obtener las coordenadas y luego pasa esas coordenadas a /v1/timezone. Si solo tienes la dirección IP de su última visita, el endpoint /v1/ip devuelve directamente un campo timezone, sin una consulta aparte.
GET /v1/timezone?lat=35.6762&lon=139.6503{
"status": "ok",
"timezone": "Asia/Tokyo",
"utc_offset": "+09:00",
"abbreviation": "JST"
}Cuando no hay registrada ni una dirección ni una IP
Para un cliente potencial o un ticket sin dirección y sin IP registrada, no hay ninguna coordenada fiable a partir de la cual consultar una zona horaria, y adivinarla a partir del prefijo telefónico del país o de una configuración de idioma no es algo que este endpoint pueda hacer por ti. En ese caso, pide directamente una zona horaria o una ubicación aproximada, en lugar de mostrar un reloj construido sobre una suposición que tiene muchas probabilidades de equivocarse en varias horas.
Mostrar el reloj
Guarda el identificador de zona horaria en la ficha del cliente y calcula a partir de él la hora local actual cada vez que se muestre el panel, en lugar de guardar un desfase fijo que quedará desactualizado con los cambios de horario de verano. Como el sitio no tiene JavaScript en el cliente, genera la hora local actual en el servidor al cargar la página y actualízala en cada solicitud de página, en lugar de hacerla avanzar en vivo en el navegador.
Una consulta por cliente, no por visita a la página
El identificador de zona horaria de la ubicación de un cliente no cambia de un día para otro, así que consúltalo una vez cuando se registre por primera vez la dirección o la IP y guarda el identificador, en lugar de llamar a la API cada vez que se cargue el panel. Así esta función se queda en unas pocas solicitudes en total en lugar de una por visita a la página, lo que importa si un equipo de soporte abre el panel muchas veces al día.
Un error que conviene evitar
Recalcular el desfase de una interacción de soporte pasada con la consulta de zona horaria de hoy, en lugar de con la marca de tiempo de la propia interacción, puede mostrar la hora equivocada en torno a un cambio de horario de verano. Si un panel necesita mostrar qué hora local era para el cliente en el momento en que se abrió un ticket pasado, pasa la marca de tiempo de ese ticket en el parámetro time en lugar de fiarte del desfase actual.
Lo que cuesta
Incluso sin guardar el identificador en caché, cada consulta es una sola solicitud, así que un equipo de soporte de cualquier tamaño razonable cabe holgadamente en las 2.500 solicitudes gratuitas al día incluidas con cada clave, o en la misma cuota desde una sola dirección sin clave.
Mantenerlo actualizado
Si cambia la dirección registrada de un cliente, actualiza al mismo tiempo el identificador de zona horaria guardado, en lugar de dejar uno obsoleto asociado a la ficha indefinidamente. Un cliente que se ha mudado y tiene un identificador de zona horaria antiguo mostrará la hora local equivocada hasta que se actualice la ficha, y lo hará sin avisar, ya que nada de la consulta antigua falla ni da error por sí solo.
Un reloj de hora local junto a un ticket es un pequeño añadido que le ahorra a un agente de soporte hacer cálculos de zonas horarias de cabeza antes de cada llamada. La documentación de consulta de zona horaria describe la solicitud por completo.