Surveillez l'utilisation de votre clé avant d'atteindre une limite
Surveiller vos en-têtes de quota au fil de l'eau vous indique quand une limite approche, bien avant qu'une requête ne soit effectivement refusée.
Ajouter une horloge d'heure locale à un tableau de bord d'assistance
Un agent d'assistance qui se demande s'il doit appeler un client maintenant a tout intérêt à savoir quelle heure il est réellement là où se trouve ce client, et non quelle heure il est au bureau.
Obtenir le fuseau horaire du client
Si vous avez déjà une adresse de livraison ou de facturation enregistrée, géocodez-la une fois pour obtenir des coordonnées, puis transmettez ces coordonnées à /v1/timezone. Si vous ne disposez que de l'adresse IP de sa dernière visite, l'endpoint /v1/ip renvoie directement un champ timezone, sans recherche supplémentaire.
GET /v1/timezone?lat=35.6762&lon=139.6503{
"status": "ok",
"timezone": "Asia/Tokyo",
"utc_offset": "+09:00",
"abbreviation": "JST"
}Lorsqu'aucune adresse ni aucune IP n'est enregistrée
Pour un prospect ou un ticket sans adresse ni IP enregistrée, il n'existe aucune coordonnée fiable à partir de laquelle rechercher un fuseau horaire, et deviner à partir d'un indicatif téléphonique ou d'un paramètre de langue n'est pas quelque chose que cet endpoint peut faire pour vous. Dans ce cas, demandez directement un fuseau horaire ou une localisation approximative, plutôt que d'afficher une horloge fondée sur une supposition qui risque réellement de se tromper de plusieurs heures.
Afficher l'horloge
Enregistrez l'identifiant de fuseau horaire dans la fiche client, puis calculez l'heure locale actuelle à partir de celui-ci à chaque affichage du tableau de bord, plutôt que d'enregistrer un décalage fixe qui deviendra obsolète lors des changements d'heure. Comme le site n'utilise pas de JavaScript côté client, générez l'heure locale actuelle côté serveur au chargement de la page et actualisez-la à chaque requête de page plutôt que de la faire défiler en direct dans le navigateur.
Une recherche par client, pas par affichage de page
L'identifiant de fuseau horaire correspondant à la localisation d'un client ne change pas d'un jour à l'autre : recherchez-le donc une seule fois, lorsque l'adresse ou l'IP est enregistrée pour la première fois, et conservez l'identifiant, plutôt que d'appeler l'API à chaque chargement du tableau de bord. Cette fonctionnalité se limite ainsi à une poignée de requêtes au total au lieu d'une par affichage de page, ce qui compte si le tableau de bord est ouvert de nombreuses fois par jour par une équipe d'assistance.
Une erreur à éviter
Recalculer le décalage d'un échange d'assistance passé à partir de la recherche de fuseau horaire du jour, plutôt qu'à partir de l'horodatage de l'échange lui-même, peut afficher une heure erronée autour d'un changement d'heure. Si un tableau de bord doit indiquer l'heure locale qu'il était pour le client au moment où un ticket passé a été créé, transmettez l'horodatage de ce ticket dans le paramètre time plutôt que de vous fier au décalage actuel.
Ce que cela coûte
Même sans mettre l'identifiant en cache, chaque recherche ne représente qu'une requête : une équipe d'assistance de taille raisonnable tient donc largement dans les 2 500 requêtes gratuites par jour incluses avec chaque clé, ou dans le même quota depuis une même adresse sans clé.
Garder les données à jour
Si l'adresse enregistrée d'un client change, actualisez en même temps l'identifiant de fuseau horaire stocké, plutôt que de laisser indéfiniment un identifiant périmé associé à la fiche. Un client qui a déménagé et dont l'identifiant de fuseau horaire est ancien verra s'afficher une heure locale erronée jusqu'à la mise à jour de la fiche, et ce sans le moindre signal, puisque rien dans l'ancienne recherche n'échoue ni ne génère d'erreur de lui-même.
Une horloge d'heure locale à côté d'un ticket est un petit ajout qui évite à un agent d'assistance de calculer des décalages horaires de tête avant chaque appel. La documentation de la recherche de fuseau horaire décrit la requête en détail.