Hoe je de Sitata API's kunt gebruiken om reisbeperkingen voor reizigers te bepalen

Velen van jullie weten het misschien niet, maar de eerste fundamenten van Sitata werden gebouwd voor de vroege detectie van ziekten. Onze oprichtster gaf zelfs al in 2016 een TedX-talk over waarom we reizigers moeten waarschuwen om de verspreiding van ziekten te voorkomen. Het is dus geen verrassing dat we op de hoogte waren van COVID-19, dat begin december 2019 werd gemeld als een ongebruikelijke cluster van longontstekingsgevallen. Op 2 januari 2020 besloot ons gezondheidsteam dat we een eerste waarschuwing moesten uitsturen naar onze reizigers en zakelijke partners. Dat was zelfs een paar dagen vóór de Wereldgezondheidsorganisatie!

Tijdens de onvermijdelijke nasleep hadden we een openbaring. De ziekte verspreidde zich zo snel dat het ons duidelijk was dat de wereldwijde reactie op zijn best chaotisch zou zijn. Elk land zou zijn eigen voorschriften en regels invoeren om de verspreiding te controleren. Dit zou onvermijdelijk wereldwijd voor ravage zorgen en een enorme bron van verwarring zijn voor degenen die nog wilden reizen. We hadden gelijk en besloten er iets aan te doen. Sitata was een van de eerste bedrijven ter wereld die een speciale API en service creëerde om veranderingen in reisbeperkingen en toegangsvoorwaarden als gevolg van COVID-19 bij te houden. Dankzij een geavanceerd softwarematig gebeurtenisdetectiesysteem en een team van gespecialiseerde analisten hadden we al alle tools en processen om dit te bereiken.

Sinds de lancering van deze nieuwe service hebben verschillende organisaties de data ten goede laten komen aan hun eigen klanten, waaronder Eddy Travels, Flight Centre en Etihad Airways; meer aankondigingen volgen binnenkort! Om meer reisgerichte organisaties te helpen van dit aanbod te profiteren, hebben we hieronder een aantal voorbeelden uitgebreid uitgewerkt om uit te leggen hoe je de API kunt gebruiken voor verschillende use cases. Hopelijk helpen deze uitleggen je om je eigen initiatieven van de grond te krijgen.

Toegangsvoorwaarden

De eerste vragen die een reiziger zich ongetwijfeld stelt, zijn: “Mag ik erheen?” en “Moet ik in quarantaine?”, dus dat is een goed startpunt. We hebben de dataset Toegangsvoorwaarden gemaakt om de lastige ja/nee-vragen over het betreden van een land of regio te beantwoorden.

Op het moment van schrijven bevatte deze dataset de volgende tien afzonderlijke categorieën:

• Mag een inwoner het land betreden?
• Mag een buitenlander het land betreden?
• Is doorreis door het land toegestaan?
• Is een test vereist bij aankomst (ziekteverschijnselen)?
• Is een testcertificaat toegestaan (ziekteverschijnselen)?
• Is quarantaine vereist bij aankomst (ziekteverschijnselen)?
• Is vaccinatie vereist?
• Is verzekering vereist?
• Is een testcertificaat vereist?
• Is een registratieformulier vereist? (gezondheid of anders)

Elke categorie kan een van de volgende waarden hebben:

• Ja
• Ja, met uitzonderingen
• Nee
• Nee, behalve uitzonderingen

Hoewel de overgrote meerderheid van de waarden “ja” en “nee” is, is de situatie in het veld niet altijd zo eenvoudig. Soms zijn er echt bizarre en gekke regels die verschillende overheden hebben ingesteld en die de soorten waarden “met uitzonderingen” nodig maken.

Een toegangsvoorwaarde is in wezen een document dat een reeks regels vastlegt die door een actor worden opgelegd aan een of meer andere landen of regio’s. De actor kan in onze data-architectuur een land, een staat of zelfs een gemeente zijn. Over het algemeen dekt Sitata momenteel data op landniveau. We hebben echter enkele staat/provincie-records voor bepaalde regio’s, zoals de Verenigde Staten en andere.

Elk record met een ingevuld veld **origin_country_division_id** of **origin_country_region_id** is respectievelijk een staat- of gemeenteniveau. Als je meer gedetailleerde data nodig hebt, neem dan contact met ons op zodat we je use case kunnen bespreken.

Neem de tijd om vertrouwd te raken met de datastructuur van de Toegangsvoorwaarden door onze API-documentatie hier te bekijken.

Een deel van de datastructuur is een beetje verwarrend, namelijk ons gebruik van de term “origin” (oorsprong). Deze verwarring komt doordat ontwikkelaars vaak denken dat de oorsprong de plaats van herkomst of vertrek is. Wat wij echter bedoelen met “origin” is eigenlijk de oorsprong van de regel die aan anderen wordt opgelegd, d.w.z. het land of de regio die de beperking heeft ingesteld.

Een ander belangrijk punt om op te merken is hoe onze lijst met getroffen landen werkt. Als affected_countries leeg is, moet dit worden geïnterpreteerd als een wereldwijde regel, d.w.z. alle landen worden getroffen.

Enkele voorbeelden

Zoals je in de documentatie hebt kunnen zien, zijn er verschillende manieren om data uit de API op te halen. Hieronder bespreken we enkele van de meest voorkomende use cases.

Hoe krijg ik de vereisten tussen twee landen?

Er zijn meerdere manieren om dit soort verzoek te doen. De eenvoudigste versie is door de parameters **destination** en **departure** te gebruiken. Deze parameters accepteren ISO 3166-1 alpha-2 codes als invoer.

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

Het antwoord bevat alle vereisten (op land- en staatniveau) die nodig zijn om te begrijpen voor de reiziger die vertrekt vanuit het vertrekland en reist naar het bestemmingsland.

Wat als ik data op staatniveau wil?

Sitata heeft data op staatniveau voor bepaalde regio’s. Je weet dat een specifieke invoer voor een staat is als het veld origin_country_division een waarde heeft. Je kunt ook filteren om alleen data op staatniveau op te halen door de parameter **destination_country_division** te gebruiken. Het verwacht een ISO_3166-2 waarde. Bijvoorbeeld US-TX voor Texas, VS.

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

Merk op dat het eenvoudiger kan zijn om op land te zoeken en dan de data te filteren op staat om te zien of die data bestaat, en deze te gebruiken als die bestaat.

Hoe krijg ik de vereisten tussen twee luchthavens?

Net als voor landen kan de Sitata API resultaten tussen twee luchthavens teruggeven. De parameters departure_airport en destination_airport gebruiken ICAO of IATA codes om resultaten te filteren. Het antwoord bevat alle beperkingen (op land- en staatniveau) die nodig zijn om te begrijpen voor de reiziger die vertrekt vanuit het bijbehorende vertrekland en reist naar het bestemmingsland.

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

Het antwoord bevat alle beperkingen (op land- en staatniveau) die nodig zijn om te begrijpen voor de reiziger die vertrekt vanuit het vertrekland en reist naar het bestemmingsland.

Wat als ik alleen stadsinformatie heb?

Sitata heeft ervoor gekozen geen verzoeken te beantwoorden voor een specifieke stadsnaam, omdat dit tot conflicten en verwarring kan leiden. In plaats daarvan hebben we ervoor gekozen om aanvragen op onze API te accepteren op basis van breedte- en lengtegraadcoördinaten, wat geen dubbelzinnigheid in onze resultatenset oplevert. De parameters zijn departure_lat, departure_lng, destination_lat en 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

Als je je steden oplost naar locaties en aanvragen doet op basis van coördinaten, zal onze API reageren met alle beperkingen (op land- en staatniveau) die nodig zijn om te begrijpen voor de reiziger die vertrekt vanuit het vertrekland en reist naar het bestemmingsland.

Extra informatie

Voor sommige soorten toegangsvoorwaarden kunnen er extra gegevens zijn gekoppeld in een metadata-type veld genaamd extras. Dit veld is een sleutel/waarde-mapping van verschillende aanvullende informatie-elementen voor een specifieke vereiste.

Wat is het aantal quarantainedagen?

Deze data-invoer valt onder toegangsvoorwaarde type 5. In deze invoer bevat de **extras** mapping een veld genaamd quarantine_days dat een geheel getal bevat voor het aantal opgelegde quarantainedagen.

Wat is het aantal uren voor binnenkomst voor een negatieve covid-test?

Deze data-invoer valt onder toegangsvoorwaarde type 8. In deze invoer bevat de **extras** mapping een veld genaamd entry_hours dat een geheel getal bevat voor het aantal uren waarbinnen een negatieve covid-test is toegestaan voor binnenkomst.

Laat het ons weten

We denken dat we een zeer robuuste tool hebben die waarschijnlijk in al je behoeften zal voorzien om je reizigers te helpen begrijpen wat ze onderweg kunnen verwachten. Als je een specifieke use case hebt die we niet behandelen, laat het ons dan weten!

Wacht… er is meer!

Dit bericht maakt deel uit van een tweedelige serie die uitlegt hoe je kunt omgaan met de Sitata API voor informatie over toegangsvoorwaarden en reisbeperkingen. Tot nu toe hebben we het gehad over toegangsvoorwaarden die de strikte ja/nee-soort voorwaarden beschrijven die nodig zijn om een land of regio binnen te komen, maar we hebben het nog niet gehad over wat er binnen het land gebeurt. Het is één ding om te weten hoe je een land binnenkomt, het is iets anders om te begrijpen of je door het land kunt reizen of de stranden kunt bezoeken of dat er een verplichte avondklok is.

Blijf op de hoogte voor het tweede artikel dat dieper ingaat op onze dataset Reisbeperkingen. Tip: het is bijna identiek, dus je kunt altijd onze API-documentatie raadplegen in de tussentijd.