Comment utiliser les API de Sitata pour déterminer les restrictions de voyage pour les voyageurs

Beaucoup d’entre vous l’ignorent peut-être, mais les premières fondations de Sitata ont été posées pour la détection précoce des maladies. En effet, notre fondatrice a donné une conférence TedX dès 2016 sur les raisons pour lesquelles nous devons avertir les voyageurs pour prévenir la propagation des maladies. Il n’est donc pas surprenant que nous ayons été informés du COVID-19, signalé comme un groupe inhabituel de cas de pneumonie début décembre 2019. Dès le 2 janvier 2020, notre équipe santé a décidé d’émettre une première alerte à nos voyageurs et partenaires commerciaux. C’était même quelques jours avant l’Organisation mondiale de la santé !

Face aux retombées inévitables, nous avons eu une révélation. La maladie se propageait si rapidement qu’il était clair pour nous que la réponse mondiale serait, au mieux, chaotique. Chaque pays allait promulguer ses propres règlements et règles pour contrôler la propagation. Cela allait inévitablement semer le chaos dans le monde entier et être une source majeure de confusion pour ceux qui souhaitaient encore voyager. Nous avions vu juste et avons décidé d’agir. Sitata a été l’une des premières entreprises au monde à créer une API dédiée et un service de suivi des changements dans les restrictions de voyage et les conditions d’entrée suite au COVID-19. Grâce à un système logiciel avancé de détection d’événements et à une équipe d’analystes spécialisés, nous avions déjà tous les outils et processus nécessaires pour y parvenir.

Depuis le lancement de ce nouveau service, plusieurs organisations ont utilisé ces données au profit de leurs propres clients, notamment Eddy Travels, Flight Centre et Etihad Airways ; d’autres annonces suivront bientôt ! Afin d’aider davantage d’organisations du secteur du voyage à bénéficier de cette offre, nous détaillons ci-dessous plusieurs exemples pour expliquer comment utiliser l’API pour divers cas d’usage. Nous espérons que ces explications vous aideront à lancer vos propres initiatives.

Conditions d’entrée

Les premières questions que se pose un voyageur sont sans aucun doute : “Puis-je m’y rendre ?” et “Vais-je être mis en quarantaine ?”. C’est donc un bon point de départ. Nous avons créé l’ensemble de données sur les conditions d’entrée pour répondre aux questions difficiles de type “oui/non” concernant l’entrée dans un pays ou une région.

Au moment de la rédaction, cet ensemble de données comprenait les dix catégories distinctes suivantes :

Un résident peut-il entrer dans le pays ?
Un étranger peut-il entrer dans le pays ?
Le transit à travers le pays est-il autorisé ?
Un test est-il exigé à l’arrivée (apparition de symptômes) ?
Un certificat de test est-il autorisé (apparition de symptômes) ?
Une quarantaine est-elle nécessaire à l’arrivée (apparition de symptômes) ?
Une vaccination est-elle requise ?
Une assurance est-elle requise ?
Un certificat de test est-il requis ?
Un formulaire d’inscription est-il requis ? (sanitaire ou autre)

Chaque catégorie peut avoir l’une des valeurs suivantes :

Oui
Oui, avec des exceptions
Non
Non, sauf exceptions

Si la grande majorité des valeurs sont “oui” et “non”, la réalité sur le terrain n’est pas toujours aussi simple. Parfois, il existe des règles vraiment bizarres et déroutantes mises en place par divers gouvernements, qui nécessitent les types de valeurs “avec exceptions”.

Une condition d’entrée est essentiellement un document qui consigne un ensemble de règles imposées par un acteur à l’encontre d’un ou plusieurs autres pays ou régions. Dans notre architecture de données, l’acteur peut être un pays, un État ou même une municipalité. Globalement, Sitata couvre actuellement les données au niveau des pays. Cependant, nous avons quelques enregistrements au niveau des États/provinces pour certaines régions, comme les États-Unis et d’autres.

Tout enregistrement ayant une valeur dans le champ **origin_country_division_id** ou **origin_country_region_id** correspond respectivement à un niveau État ou municipal. Si vous avez besoin de données plus granulaires, veuillez nous contacter et nous pourrons discuter de votre cas d’usage.

Prenez le temps de vous familiariser avec la structure des données des conditions d’entrée en consultant notre documentation API ici.

Un aspect de la structure des données peut prêter à confusion, à savoir notre utilisation du terme “origin” (origine). Cette confusion vient du fait que les développeurs considèrent souvent l’origine comme le lieu de provenance ou de départ. Or, ce que nous entendons par “origine” est en fait la source de la règle imposée aux autres, c’est-à-dire le pays ou la région qui a créé la restriction.

Un autre point important à noter est le fonctionnement de notre liste affected_countries. Si affected_countries est vide, cela doit être interprété comme une règle globale, c’est-à-dire que tous les pays sont concernés.

Quelques exemples

Comme vous avez pu le voir dans la documentation, il existe plusieurs façons de récupérer les données de l’API. Ci-dessous, nous allons passer en revue quelques-uns des cas d’usage les plus courants.

Comment obtenir les exigences entre deux pays ?

Il existe plusieurs façons de faire ce type de requête. La version la plus simple consiste à utiliser les paramètres **destination** et **departure**. Ces paramètres acceptent les codes ISO 3166-1 alpha-2 comme entrées.

GET https://www.sitata.com/api/v2/entry_requirements?departure=DE&destination=IN

La réponse inclura toutes les exigences (au niveau du pays et de l’État) nécessaires pour comprendre ce à quoi le voyageur partant du pays de départ et se rendant dans le pays de destination doit se conformer.

Et si je veux des données au niveau de l’État ?

Sitata dispose de données au niveau de l’État pour certaines régions. Vous saurez qu’une entrée particulière concerne un État si le champ origin_country_division a une valeur. Vous pouvez également filtrer pour ne récupérer que les données au niveau de l’État en utilisant le paramètre **destination_country_division**. Il attend une valeur ISO_3166-2. Par exemple, US-TX pour le Texas, États-Unis.

GET https://www.sitata.com/api/v2/entry_requirements?departure=DE&destination_country_division=IN-AP

Notez qu’il pourrait être plus simple d’effectuer une recherche par pays, puis de filtrer les données par État pour voir si ces données existent, et de les utiliser le cas échéant.

Comment puis-je obtenir les exigences entre deux aéroports ?

Tout comme pour les pays, l’API Sitata peut renvoyer les résultats entre deux aéroports. Les paramètres departure_airport et destination_airport utilisent les codes OACI ou IATA pour filtrer les résultats. La réponse comprendra toutes les restrictions (au niveau du pays et de l’État) nécessaires à la compréhension du voyageur partant du pays de départ correspondant et se rendant dans le pays de destination.

GET https://www.sitata.com/api/v2/entry_requirements?departure_airport=MUC&destination_airport=BOM

La réponse comprendra toutes les restrictions (au niveau du pays et de l’État) nécessaires pour comprendre ce à quoi le voyageur partant du pays de départ et se rendant dans le pays de destination doit se conformer.

Et si je n’ai que des informations sur la ville ?

Sitata a choisi de ne pas répondre aux requêtes basées sur un nom de ville spécifique, car cela pourrait entraîner des conflits et des confusions. Au lieu de cela, nous avons choisi d’accepter les requêtes de notre API par coordonnées de latitude et de longitude, ce qui ne génère aucune ambiguïté dans nos résultats. Les paramètres sont departure_lat, departure_lng, destination_lat et destination_lng.

GET https://www.sitata.com/api/v2/entry_requirements?departure_lat=48.13743&departure_lng=11.57549&destination_lat=19.0760&destination_lng=72.8777

Si vous géolocalisez vos villes et effectuez des requêtes basées sur les coordonnées, notre API répondra avec toutes les restrictions (au niveau du pays et de l’État) nécessaires pour comprendre ce à quoi le voyageur partant du pays de départ et se rendant dans le pays de destination doit se conformer.

Informations supplémentaires

Pour certains types de conditions d’entrée, il peut y avoir des données supplémentaires associées dans un champ de métadonnées appelé extras. Ce champ est un mapping clé/valeur de divers éléments d’information supplémentaires pour une exigence particulière.

Quel est le nombre de jours de quarantaine ?

Cette donnée est liée à l’exigence d’entrée de type 5. Dans cette entrée, le mapping **extras** contiendra un champ appelé quarantine_days qui contiendra un entier correspondant au nombre de jours de quarantaine imposés.

Quel est le nombre d’heures avant l’entrée pour un test covid négatif ?

Cette donnée est liée à l’exigence d’entrée de type 8. Dans cette entrée, le mapping **extras** contiendra un champ appelé entry_hours qui contiendra un entier correspondant au nombre d’heures pendant lesquelles un test covid négatif est valable avant l’entrée.

Faites-nous part de vos besoins

Nous pensons disposer d’un outil très robuste qui répondra probablement à tous vos besoins pour aider vos voyageurs à comprendre ce qu’ils sont susceptibles de rencontrer en chemin. Si vous avez un cas d’usage particulier que nous ne couvrons pas, faites-le nous savoir !

Attendez… il y a plus !

Cet article fait partie d’une série en deux parties qui explique comment interagir avec l’API Sitata pour les informations sur les conditions d’entrée et les restrictions de voyage. Jusqu’à présent, nous avons parlé des conditions d’entrée qui décrivent les types de conditions strictes de type oui/non nécessaires pour entrer dans un pays ou une région, mais nous n’avons pas encore abordé ce qui se passe à l’intérieur du pays. C’est une chose de savoir comment entrer dans un pays, c’en est une autre de comprendre s’il est possible de s’y déplacer, de visiter les plages ou s’il y a un couvre-feu obligatoire.

Restez à l’écoute pour le deuxième article qui approfondira notre série de données sur les restrictions de voyage. Indice : elle est presque identique, donc vous pouvez toujours consulter notre documentation API en attendant.