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

Beaucoup d’entre vous ne le savent peut-être pas, mais les premières fondations de Sitata ont été construites pour la détection précoce des maladies. En effet, notre fondateur a donné une conférence TedX en 2016 sur pourquoi nous devons avertir les voyageurs pour aider à prévenir la propagation des maladies. Il ne devrait donc pas être surprenant que nous ayons appris l’existence du COVID-19 lorsqu’un groupe inhabituel de cas de pneumonie a été signalé début décembre 2019. Le 2 janvier 2020, notre équipe santé a déterminé que nous devions émettre notre premier avertissement à nos voyageurs et partenaires commerciaux. C’était même plusieurs jours avant l’Organisation Mondiale de la Santé !

Pendant les retombées inévitables, nous avons eu une épiphanie. La maladie se propageait si rapidement qu’il était clair que la réponse mondiale serait chaotique au mieux. Chaque pays promulguerait son propre ensemble de règlements et de règles pour contrôler la propagation. Cela causerait inévitablement des ravages sur les voyages mondiaux et serait une énorme source de confusion pour ceux qui souhaitent encore voyager. Nous avions raison et nous nous sommes mis en tête d’y remédier. Sitata a été l’une des premières entreprises au monde à créer une API dédiée et un service de surveillance pour les changements dans les restrictions de voyage et les conditions d’entrée résultant du COVID-19. Avec un système logiciel avancé de détection d’événements et une équipe dédiée d’analystes, nous avions déjà tous les outils et processus appropriés pour le faire.

Depuis le lancement de ce nouveau service, diverses organisations ont exploité les données au profit de leurs propres clients, notamment Eddy Travels, Flight Centre et Etihad Airways ; et d’autres seront annoncées bientôt ! Afin d’aider davantage d’organisations axées sur les voyages à bénéficier de cette offre, nous avons rédigé ci-dessous en détail une série d’exemples pour expliquer comment utiliser l’API pour divers cas d’utilisation. J’espère que ces explications vous aideront à lancer vos propres initiatives.

Conditions d’entrée

Sans aucun doute, les premières questions qu’un voyageur se pose sont “puis-je y aller ?” et “vais-je être mis en quarantaine ?”, c’est donc un bon point de départ. Nous avons créé l’ensemble de données des Conditions d’Entrée pour répondre aux durs “oui/non” des questions relatives à l’entrée dans un pays ou une région.

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

Un résident peut-il entrer dans le pays ?
Un étranger peut-il entrer dans le pays ?
Le transit par le pays est-il autorisé ?
Un test à l’arrivée est-il requis (épidémie de maladie) ?
Un certificat de test est-il autorisé (épidémie de maladie) ?
Une quarantaine à l’arrivée est-elle requise (épidémie de maladie) ?
Un vaccin est-il requis ?
Une assurance est-elle requise ?
Un certificat de test est-il requis ?
Un formulaire d’inscription est-il requis ? (santé ou autre)

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

Oui
Oui, avec des exceptions
Non
Non, avec des exceptions

Bien que la grande majorité des valeurs soient “oui” et “non”, la situation sur le terrain n’est pas toujours aussi simple. Parfois, il existe des règles vraiment étranges et folles que divers gouvernements ont mises en place et qui nécessitent les types de valeurs “avec des exceptions”.

Une condition d’entrée est essentiellement un enregistrement qui documente un ensemble de règles imposées par un acteur contre un ou plusieurs pays ou régions. L’acteur pourrait être un pays, un État ou même une municipalité dans notre architecture de données. En général, Sitata couvre les données au niveau national pour le moment. Cependant, nous avons quelques enregistrements au niveau des États/provinces pour des régions sélectionnées comme les États-Unis et d’autres.

Tout enregistrement qui a une entrée dans le champ **origin_country_division_id** ou **origin_country_region_id** est un enregistrement au niveau de l’État ou de la municipalité, respectivement. Si vous souhaitez obtenir des données plus granulaires, veuillez nous contacter et nous pouvons discuter de votre cas d’utilisation.

Prenez le temps de vous familiariser avec la structure des données des conditions d’entrée en jetant un coup d’œil à notre documentation API ici.

Un point un peu déroutant concernant la structure des données est notre utilisation du terme “origine”. C’est déroutant car les développeurs pensent souvent que l’origine est le lieu d’origine ou de départ. Cependant, ce que nous entendons par origine est en fait l’origine 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 des pays affectés. Si affected_countries est vide, cela doit être interprété comme une règle globale, c’est-à-dire que tous les pays sont affectés.

Quelques exemples

Comme vous l’avez peut-être vu dans la documentation, il existe plusieurs façons de récupérer des données de l’API. Nous allons examiner ci-dessous certains des cas d’utilisation les plus courants.

Comment puis-je obtenir les conditions 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 conditions (au niveau du pays et de l’État) nécessaires à comprendre pour le voyageur partant du pays de départ et se rendant dans le pays de destination.

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_id a une valeur. Vous pouvez également filtrer pour récupérer uniquement 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’interroger par pays, puis de filtrer les données des États pour voir si elles existent, et de les utiliser si c’est le cas.

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

Comme pour les pays, l’API de Sitata peut renvoyer des 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 inclura toutes les restrictions (au niveau du pays et de l’État) nécessaires à comprendre pour le 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 inclura toutes les restrictions (au niveau du pays et de l’État) nécessaires à comprendre pour le voyageur partant du pays de départ et se rendant dans le pays de destination.

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

Sitata a choisi de ne pas prendre en charge les requêtes par nom de ville spécifique, car cela pourrait entraîner des conflits et de la confusion. Au lieu de cela, nous avons choisi de prendre en charge les requêtes vers notre API par coordonnées de latitude et de longitude, ce qui ne produit aucune ambiguïté dans notre ensemble de 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 résolvez vos villes en emplacements et interrogez sur la base des coordonnées, notre API répondra avec toutes les restrictions (au niveau du pays et de l’État) nécessaires à comprendre pour le voyageur partant du pays de départ et se rendant dans le pays de destination.

Données 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 type métadonnées appelé extras. Ce champ est un mappage clé/valeur de divers bits d’informations supplémentaires pour une condition particulière.

Quel est le nombre de jours de quarantaine ?

Cette entrée de données est soumise à la condition d’entrée type 5. Dans cette entrée, le mappage **extras** contiendra un champ appelé quarantine_days qui contiendra un entier pour le nombre de jours de quarantaine imposés.

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

Cette entrée de données est soumise à la condition d’entrée type 8. Dans cette entrée, le mappage **extras** contiendra un champ appelé entry_hours qui contiendra un entier pour le nombre d’heures pendant lesquelles un test COVID négatif est autorisé avant l’entrée.

Faites-nous savoir

Nous pensons avoir une API très robuste qui répondra probablement à tous vos besoins pour aider vos voyageurs à comprendre ce qu’ils sont susceptibles de rencontrer sur la route. Si vous avez un cas d’utilisation particulier que nous ne couvrons pas, veuillez nous en informer !

Attendez… il y a plus !

Cet article fait partie d’une série en deux parties expliquant comment interagir avec l’API de Sitata pour les conditions d’entrée et les informations sur 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 non plus parlé de ce qui se passe à l’intérieur du pays. Une chose est de savoir comment entrer dans un pays, et une autre est de comprendre s’il est possible de se déplacer dans le pays, de visiter les plages ou s’il y a un couvre-feu obligatoire.

Restez à l’écoute pour le deuxième article qui plongera dans notre ensemble de données sur les Restrictions de Voyage. Indice - c’est presque identique, donc vous pouvez toujours jeter un coup d’œil à notre documentation API en attendant.