Hur man använder Sitata:s API:er för att fastställa resebegränsningar för resenärer

Många av er kanske inte vet detta, men Sitatas tidiga grund byggdes för tidig sjukdomsupptäckt. Vår grundare har faktiskt ett TedX-föredrag från 2016 som handlar om varför vi måste varna resenärer för att förhindra sjukdomsspridning. Det borde därför inte vara någon överraskning att vi uppmärksammade COVID-19 när det rapporterades som ett ovanligt kluster av pneumonifall i början av december 2019. Den 2 januari 2020 hade vårt hälsoteam bestämt att vi skulle ge ut vår första varning till våra resenärer och affärspartner. Detta var dagar före till och med Världshälsoorganisationen!

Under den oundvikliga eftersläpningen fick vi en ingivelse. Sjukdomen spred sig så snabbt att det var tydligt för oss att det globala svaret skulle bli kaotiskt i bästa fall. Varje land skulle införa sina egna regler och bestämmelser för hur spridningen skulle kontrolleras. Detta skulle oundvikligen skapa kaos för den globala resandet och vara en stor källa till förvirring för dem som fortfarande vill 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 som skapade ett dedikerat API och en övervakningstjänst för förändringar i resebegränsningar och inträdeskrav som ett resultat av COVID-19. Med ett avancerat mjukvarusystem för händelseupptäckt och ett dedikerat team av analytiker hade vi redan alla rätt verktyg och processer på plats för att göra det.

Sedan vi lanserade denna nya tjänst har en rad olika organisationer dragit nytta av datan till fördel för sina egna kunder, inklusive Eddy Travels, Flight Centre och Etihad Airways; och fler kommer att tillkännages 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. Jag hoppas att dessa förklaringar hjälper dig att komma igång med dina egna initiativ.

Inträdeskrav

Utan tvegan är de första frågorna en resenär ställer “kan jag åka dit?” och “kommer jag att sättas i karantän?” så det är en bra plats att börja. Vi skapade datamängden Inträdeskrav för att besvara de svåra “ja/nej”-frågorna om att komma in i ett land eller en region.

Vid tidpunkten för skrivandet innehöll denna datamängd följande 10 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 testintyg tillåtet (sjukdomsutbrott)?
• Krävs karantän vid ankomst (sjukdomsutbrott)? Krävs vaccination?
• Krävs försäkring?
• Krävs testintyg?
• Krävs inträdesblankett? (hälsa eller annat)

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

• Ja
• Ja, med undantag
• Nej
• Nej, med undantag

Medan de allra flesta värdena är “ja” och “nej”, är situationen på plats inte alltid så enkel. Ibland finns det riktigt konstiga och galna regler som olika regeringar har infört, vilket kräver värdena “med undantag”.

Ett inträdeskrav är i grunden en post som dokumenterar 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 delstat eller till och med en kommun i vår dataarkitektur. I stort sett täcker Sitata för närvarande data på landsnivå. Vi har dock vissa poster på delstats-/provinsnivå för utvalda 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 antingen på delstats- respektive kommunnivå. Om du vill ha mer detaljerad data tillgänglig, kontakta oss så kan vi prata om ditt användningsfall.

Ta dig tid att bekanta dig med datastrukturen för inträdeskrav genom att titta på vår API-dokumentation här.

En lite förvirrande del av datastrukturen är vår användning av termen “origin”. Detta är förvirrande eftersom utvecklare ofta tänker på “origin” som ursprungsplats eller avreseställe. Men vad vi menar med “origin” är faktiskt ursprunget för regeln som införts mot andra, dvs. det land eller den region som har skapat 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 vanligare användningsfallen.

Hur hämtar jag kraven mellan två länder?

Det finns ett par sätt att göra den här typen 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 att förstå för resenären som reser från avreselandet 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 fältet origin_country_division har ett värde. Du kan också filtrera för att endast hämta data på delstatsnivå med 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 fråga efter land och sedan filtrera på delstatsdata för att se om sådan data finns, och använda den om den finns.

Hur hämtar 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 antingen 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 att förstå för resenären som reser från motsvarande avreseland 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 att förstå för resenären som reser från avreselandet till destinationslandet.

Vad händer om jag bara har stadsinformation?

Sitata valde att inte hantera förfrågningar efter ett visst stadsnamn eftersom det kan leda till konflikter och förvirring. Istället valde vi att möjliggöra förfrågningar till vårt API med 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 översätter dina städer till platser och frågar baserat på koordinater kommer vårt API att svara med alla begränsningar (på lands- och delstatsnivå) som är nödvändiga för att förstå för resenären som reser från avreselandet till destinationslandet.

Extra data

För vissa typer av inträdeskrav kan det finnas extra tillhörande data i ett metadatafält av typen extras. Detta fält är en nyckel/värde-mappning av olika extra informationsbitar för ett specifikt krav.

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

Denna datapost faller under inträdeskravet 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 dagars karantän som påförts.

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

Denna datapost faller under inträdeskravet 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 som ett negativt covid-test är giltigt före inträde.

Berätta för oss

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

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 inträdeskrav och resebegränsningsinformation. Hittills har vi pratat om inträdeskrav som beskriver de hårda ja/nej-kraven för att komma in i ett land eller en region, men vi har inte pratat om vad som händer inuti landet heller. Det är en sak att veta om att åka in i ett land, det är en annan att förstå om det är möjligt att röra sig i landet eller besöka stränderna eller om det finns en obligatorisk utegångsförbud.

Håll utkik efter det andra inlägget som kommer att fördjupa sig i vår datamängd för resebegränsningar. Ledtråd - den är nästan identisk så du kan alltid titta på vår API-dokumentation under tiden.