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é construites pour la détection précoce des maladies. En fait, notre fondateur a donné une conférence TedX en 2016 sur la nécessité d’avertir les voyageurs pour aider à prévenir la propagation des maladies. Il n’est donc pas surprenant que nous ayons repéré le COVID-19 lorsqu’il a été 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é que nous devions publier notre premier avertissement à nos voyageurs et partenaires commerciaux. C’était plusieurs jours avant même l’Organisation Mondiale de la Santé !

Pendant les retombées inévitables, nous avons eu une révélation. La maladie se propageait si vite qu’il nous est apparu clairement que la réponse mondiale serait au mieux chaotique. Chaque pays mettrait en place son propre ensemble de règlements et de règles pour contrôler la propagation. Cela allait inévitablement semer le chaos dans les voyages internationaux et être une source majeure de confusion pour ceux qui souhaitaient encore voyager. Nous avions raison et nous 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 pour les changements dans les restrictions de voyage et les conditions d’entrée dus au 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 nécessaires pour le faire.

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

Conditions d’entrée

Sans aucun doute, les premières questions d’un voyageur 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 “Conditions d’entrée” pour répondre aux questions fermées 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 10 catégories distinctes suivantes :

Un résident peut-il entrer dans le pays ?
Un étranger peut-il entrer dans le pays ?
Le transit est-il autorisé à travers le pays ?
Un test est-il requis à l’arrivée (épidémie) ?
Un certificat de test est-il autorisé (épidémie) ?
Une quarantaine est-elle requise à l’arrivée (épidémie) ?
Un vaccin est-il requis ?
Une assurance est-elle requise ?
Un certificat de test est-il requis ?
Un formulaire d’entrée est-il requis ? (sanitaire 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, ce qui nécessite les types de valeurs “avec exceptions”.

Une Condition d’entrée est essentiellement un enregistrement documentant un ensemble de règles imposées par un acteur à un ou plusieurs autres pays ou régions. L’acteur peut être un pays, un État, ou même une municipalité dans notre architecture de données. En grande partie, Sitata couvre actuellement les données au niveau national. Cependant, nous avons bien des enregistrements au niveau État/Province pour certaines régions 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 respectivement au niveau de l’État ou de la municipalité. Si vous souhaitez des données plus granulaires, contactez-nous et nous pourrons discuter de votre cas d’usage.

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

Un point légèrement déroutant dans la structure de données est notre utilisation du terme “origin”. C’est déroutant car souvent les développeurs pensent à l’origine comme étant le lieu d’origine ou le lieu 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 avez pu le voir dans la documentation, il existe plusieurs façons de récupérer des données via l’API. Ci-dessous, nous allons parcourir quelques-uns des cas d’usage les plus courants.

Comment récupérer les conditions entre deux pays ?

Il existe plusieurs façons de faire ce type de requête. La version la plus simple est d’utiliser les paramètres **destination** et **departure**. Ces paramètres acceptent des codes ISO 3166-1 alpha-2 en entrée.

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

La réponse inclura toutes les conditions (au niveau pays et É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 des États ?

Sitata dispose bien de données au niveau des États 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 des États 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 peut être plus simple de faire une requête par pays, puis de filtrer par données d’État pour voir si de telles données existent, et de les utiliser si elles existent.

Comment récupérer les conditions entre deux aéroports ?

Tout comme pour les pays, l’API Sitata peut retourner des résultats entre deux aéroports. Les paramètres departure_airport et destination_airport utilisent soit des codes ICAO soit IATA pour filtrer les résultats. La réponse inclura toutes les restrictions (au niveau pays et É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 pays et É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 permettre l’interrogation de notre API par coordonnées de latitude et de longitude, ce qui ne produit 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 résolvez vos villes en localisations et interrogez sur la base des coordonnées, notre API répondra avec toutes les restrictions (au niveau pays et É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 mapping clé/valeur de divers éléments d’information supplémentaires pour une condition particulière.

Quel est le nombre de jours de quarantaine ?

Cette entrée de données relève de la condition d’entrée type 5. Dans cette entrée, le mapping **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 relève de la condition d’entrée type 8. Dans cette entrée, le mapping **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 solution 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… ce n’est pas tout !

Cette entrée 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 exigences de type oui/non nécessaires pour entrer dans un pays ou une région, mais nous n’avons pas parlé de ce qui se passe à l’intérieur du pays non plus. C’est une chose de savoir si on peut 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 plongera en profondeur dans notre ensemble de données sur les Restrictions de voyage. Indice - c’est presque identique, donc vous pouvez toujours jeter un œil à notre documentation API en attendant.