Hur man använder Sitata API:er för att avgöra resebegränsningar för resenärer

Många av er kanske inte vet det, men de första grundvalarna för Sitata byggdes för tidig upptäckt av sjukdomar. Vår grundare höll faktiskt ett TedX-tal redan 2016 om varför vi måste varna resenärer för att förhindra sjukdomsspridning. Så det är inte förvånande att vi fick kännedom om COVID-19, som rapporterades som en ovanlig grupp av pneumonifall i början av december 2019. Den 2 januari 2020 beslutade vårt hälsoteam att vi behövde ge ut ett tidigt varning till våra resenärer och affärspartner. Detta var några dagar före till och med Världshälsoorganisationen!

Under de oundvikliga efterskalven fick vi en insikt. Sjukdomen spred sig så snabbt att det var tydligt för oss att den globala responsen skulle bli kaotisk i bästa fall. Varje land skulle införa sina egna regler och bestämmelser för att kontrollera spridningen. Detta skulle oundvikligen skapa kaos världen över och vara en enorm källa till förvirring för dem som fortfarande ville resa. Vi hade rätt och vi bestämde oss för att göra något åt det. Sitata var ett av de första företagen i världen att skapa ett dedikerat API och en tjänst för att spåra förändringar i resebegränsningar och inträdesvillkor som följd av COVID-19. Tack vare ett avancerat mjukvarusystem för händelseupptäckt och ett team av specialiserade analytiker hade vi redan alla verktyg och processer på plats för att uppnå detta.

Sedan lanseringen av denna nya tjänst har flera organisationer dragit nytta av datan till fördel för sina egna kunder, inklusive Eddy Travels, Flight Centre och Etihad Airways; fler tillkännagivanden kommer snart! För att hjälpa fler reseinriktade organisationer att dra nytta av detta erbjudande har vi nedan skrivit i detalj ett antal exempel för att förklara hur man använder API:et för olika användningsfall. Förhoppningsvis hjälper dessa förklaringar dig att komma igång med dina egna initiativ.

Inträdesvillkor

De första frågorna en resenär utan tvekan ställer sig är “Kan jag åka dit?” och “Kommer jag att behöva sättas i karantän?”, så det är en bra utgångspunkt. Vi skapade inträdesvillkors-datasetet för att besvara de svåra ja/nej-frågorna om inträde till ett land eller en region.

Vid tidpunkten för skrivandet innehöll detta dataset följande tio distinkta kategorier:

• Kan en invånare komma in i landet?
• Kan en utlänning komma in i landet?
• Är transit genom landet tillåten?
• Krävs ett test vid ankomst (sjukdomsutbrott)?
• Är ett testcertifikat tillåtet (sjukdomsutbrott)?
• Krävs karantän vid ankomst (sjukdomsutbrott)?
• Krävs vaccination?
• Krävs försäkring?
• Krävs testcertifikat?
• Krävs registreringsformulär? (hälsa eller annat)

Varje kategori kan ha ett av följande värden:

• Ja
• Ja, med undantag
• Nej
• Nej, förutom undantag

Även om de allra flesta värden är “ja” och “nej”, är situationen på marken inte alltid så enkel. Ibland finns det riktigt bisarra och galna regler som olika regeringar har infört som kräver “med undantag”-typer av värden.

Ett inträdesvillkor är i grunden ett dokument som beskriver en uppsättning regler som införts av en aktör mot ett eller flera andra länder eller regioner. Aktören kan vara ett land, en stat eller till och med en kommun i vår dataarkitektur. Övergripande täcker Sitata för närvarande data på landsnivå. Vi har dock några poster på delstats-/provinsnivå för vissa regioner, som USA och andra.

Alla poster som har ett värde i fältet **origin_country_division_id** eller **origin_country_region_id** är på respektive delstatsnivå eller kommunal nivå. Om du vill ha mer detaljerad data, vänligen kontakta oss så kan vi diskutera ditt användningsfall.

Ta dig tid att bekanta dig med datastrukturen för inträdesvillkor genom att kolla in vår API-dokumentation här.

En del av datastrukturen kan vara lite förvirrande, nämligen vår användning av termen “origin” (ursprung). Denna förvirring beror på att utvecklare ofta tänker på ursprung som hemvist eller avgångsplats. Vad vi menar med “origin” är faktiskt ursprunget för regeln som införts mot andra, det vill säga landet eller regionen som skapade begränsningen.

En annan viktig punkt att notera är hur vår lista över berörda länder fungerar. Om affected_countries är tom, ska det tolkas som en global regel, dvs. alla länder är berörda.

Några exempel

Som du kanske har sett i dokumentationen finns det flera sätt att hämta data från API:et. Nedan går vi igenom några av de vanligaste användningsfallen.

Hur får man kraven mellan två länder?

Det finns flera sätt att göra denna typ av förfrågan. Den enklaste versionen är att använda parametrarna **destination** och **departure**. Dessa parametrar accepterar ISO 3166-1 alpha-2-koder som indata.

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

Svaret kommer att inkludera alla krav (på lands- och delstatsnivå) som är nödvändiga för resenären att förstå när denne reser från avgångslandet till destinationslandet.

Vad händer om jag vill ha data på delstatsnivå?

Sitata har data på delstatsnivå för vissa regioner. Du kommer att veta att en specifik post är för en delstat om origin_country_division har ett värde. Du kan också filtrera för att endast hämta data på delstatsnivå genom att använda parametern **destination_country_division**. Den förväntar sig ett ISO_3166-2-värde. Till exempel US-TX för Texas, USA.

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

Observera att det kan vara enklare att söka per land och sedan filtrera datan efter delstat för att se om sådan data finns, och använda den om den gör det.

Hur får jag kraven mellan två flygplatser?

Precis som med länder kan Sitata API returnera resultat mellan två flygplatser. Parametrarna departure_airport och destination_airport använder ICAO- eller IATA-koder för att filtrera resultaten. Svaret kommer att inkludera alla begränsningar (på lands- och delstatsnivå) som är nödvändiga för resenären att förstå när denne reser från motsvarande avgångsland till destinationslandet.

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

Svaret kommer att inkludera alla begränsningar (på lands- och delstatsnivå) som är nödvändiga för resenären att förstå när denne reser från avgångslandet till destinationslandet.

Vad händer om jag bara har stadsinformation?

Sitata har valt att inte svara på förfrågningar baserade på ett specifikt stadsnamn, eftersom detta kan leda till konflikter och förvirring. Istället har vi valt att acceptera förfrågningar till vårt API via latitud- och longitudkoordinater, vilket inte skapar någon tvetydighet i vårt resultat. Parametrarna är departure_lat, departure_lng, destination_lat och 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

Om du löser dina städer till platser och gör förfrågningar baserade på koordinater, kommer vårt API att svara med alla begränsningar (på lands- och delstatsnivå) som är nödvändiga för resenären att förstå när denne reser från avgångslandet till destinationslandet.

Ytterligare information

För vissa typer av inträdesvillkor kan det finnas ytterligare data associerade i ett metadata-typ fält som heter extras. Detta fält är en nyckel/värde-mappning av olika bitar av ytterligare information för ett specifikt krav.

Hur många dagars karantän krävs?

Denna datapost är föremål för inträdesvillkor typ 5. I denna post kommer **extras**-mappningen att innehålla ett fält som heter quarantine_days som kommer att innehålla ett heltal för antalet pålagda karantändagar.

Hur många timmar före inträde krävs ett negativt covid-test?

Denna datapost är föremål för inträdesvillkor typ 8. I denna post kommer **extras**-mappningen att innehålla ett fält som heter entry_hours som kommer att innehålla ett heltal för antalet timmar ett negativt covid-test är giltigt före inträde.

Låt oss veta

Vi tror att vi har ett mycket robust verktyg som sannolikt kommer att möta alla dina behov för att hjälpa dina resenärer att förstå vad de kan komma att möta på vägen. Om du har ett specifikt användningsfall som vi inte täcker, låt oss veta!

Vänta… det finns mer!

Detta inlägg är del ett av en tvådelad serie som förklarar hur man interagerar med Sitata API för information om inträdesvillkor och resebegränsningar. Hittills har vi pratat om inträdesvillkor som beskriver de strikta ja/nej-typerna av villkor som krävs för att komma in i ett land eller en region, men vi har inte heller pratat om vad som händer inuti landet. Det är en sak att veta hur man kommer in i ett land, det är en annan att förstå om det är möjligt att röra sig runt i landet eller besöka stränderna eller om det finns en obligatorisk utegångsförbud.

Håll ögonen öppna för den andra artikeln som kommer att fördjupa sig i vårt dataset för resebegränsningar. Ledtråd: det är nästan identiskt, så du kan alltid kolla in vår API-dokumentation under tiden.