Många av er kanske inte vet det, men Sitatas tidiga grund byggdes för tidig upptäckt av sjukdomar. Faktum är att vår grundare har ett TedX-talk från 2016 som handlar om varför vi måste varna resenärer för att förhindra att sjukdomar sprids. Det borde därför inte komma som någon överraskning att vi tog upp covid-19 när det rapporterades som ett ovanligt kluster av fall av lunginflammation i början av december 2019. Den 2 januari 2020 bestämde vårt hälsoteam att vi skulle utfärda vår första varning till våra resenärer och affärspartners. Detta var dagar innan ens Världshälsoorganisationen!
Under det oundvikliga nedfallet fick vi en uppenbarelse. Sjukdomen spreds så snabbt att det stod klart för oss att det globala svaret i bästa fall skulle bli kaotiskt. Varje land skulle anta sina egna bestämmelser och regler för hur man skulle kontrollera spridningen. Detta skulle oundvikligen skapa kaos för det globala resandet och vara en enorm 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 särskilt API och en övervakningstjänst för ändringar av reserestriktioner och inresekrav till följd av covid-19. Med ett avancerat mjukvarusystem för händelsedetektering och ett dedikerat team av analytiker hade vi redan alla rätt verktyg och processer på plats för att göra detta.
Sedan lanseringen av den här nya tjänsten har vi haft en mängd olika organisationer som drar nytta av uppgifterna till förmån för sina egna kunder, inklusive Eddy Travels, Flight Centre och Etihad Airways; och det finns fler att tillkännage snart! För att hjälpa fler resefokuserade organisationer att dra nytta av detta erbjudande har vi skrivit i detalj nedan ett antal exempel som hjälper till att förklara hur man använder API: et för en mängd olika användningsfall. Jag hoppas att dessa förklaringar hjälper dig att få igång dina egna initiativ.
Utan tvekan är de första frågorna som en resenär ställer "kan jag åka dit?" och "kommer jag att sättas i karantän" och därför är detta en bra plats att börja på. Vi skapade datasetet Entry Requirements för att besvara de svåra "ja/nej"-frågorna om att resa in i ett land eller en region.
I skrivande stund omfattade denna datauppsättning följande 10 olika kategorier:
Varje kategori kan ha ett av följande värden:
Även om de allra flesta värdena är "ja" och "nej" är situationen på fältet inte alltid så okomplicerad. Ibland finns det riktigt konstiga och galna regler som olika regeringar har infört, vilket gör det nödvändigt att använda värdetypen "med undantag".
Ett Entry Requirement är i huvudsak en post som dokumenterar en uppsättning regler som en aktör infört 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. I stort sett täcker Sitata för närvarande data på landsnivå. Vi har dock vissa statliga/provinsiella poster för utvalda regioner som USA och andra.
Varje post som har en post under fältet ursprung_land_division_id eller ursprung_land_region_id är en som är antingen statlig eller kommunal nivå, respektive. Om du vill ha mer detaljerade data tillgängliga, vänligen Kontakta oss så kan vi prata om ditt användningsfall.
Ta lite tid på dig att bekanta dig med Entry Requirement-datastrukturen genom att ta en titt på våra API-dokument här.
En något förvirrande del av datastrukturen är vår användning av termen "ursprung." Detta är förvirrande eftersom utvecklare ofta tänker på ursprung som platsen där man börjar eller slutar. Men vad vi menar med ursprung är faktiskt ursprunget till den regel som åläggs andra, dvs. det land eller den region som har skapat begränsningen.
En annan viktig punkt att notera är hur vår lista över påverkade länder fungerar. Om affected_countries är tomt ska det tolkas som en global regel, dvs. alla länder påverkas.
Som du kanske har sett i dokumentationen finns det ett antal olika sätt att hämta data från API:et. Nedan går vi igenom några av de vanligaste användningsområdena.
Det finns ett par olika sätt att göra den här typen av förfrågan. Den enklaste versionen är att använda destination och avresa parametrar. Dessa parametrar accepterar ISO 3166-1 alfa-2 koder som indata.
GET https://www.sitata.com/api/v2/entry_requirements?departure=DE&destination=INSvaret kommer att omfatta alla krav (på lands- och delstatsnivå) som är nödvändiga för att förstå för resenären som avreser från avgångslandet och reser till destinationslandet.
Sitata har uppgifter på delstatsnivå för vissa regioner. Du vet att en viss post är för en delstat om ursprung_land_indelning fältet har ett värde. Du kan också filtrera så att du bara hämtar data på delstatsnivå med hjälp av destination_land_division parameter. Den förväntar sig en 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-APObservera att det kan vara enklare att göra en förfrågan per land och sedan filtrera efter delstatsdata för att se om sådana data finns, och använda dem om de finns.
Precis som med länder kan Sitata API returnera resultat mellan två flygplatser. Parametrarna avgång_flygplats och destination_flygplats använd antingen ICAO eller IATA koder för att filtrera resultaten. Svaret kommer att innehålla alla restriktioner (på lands- och statsnivå) som är nödvändiga för att förstå för resenären som avreser från motsvarande avgångsland och reser till destinationslandet.
GET https://www.sitata.com/api/v2/entry_requirements?departure_airport=MUC&destination_airport=BOMSvaret ska omfatta alla restriktioner (på lands- och delstatsnivå) som är nödvändiga att förstå för resenären som avreser från avgångslandet och reser till destinationslandet.
Sitata valde att inte hantera sökningar efter ett visst stadsnamn eftersom det skulle kunna leda till konflikter och förvirring. Istället valde vi att göra det möjligt att ställa frågor till vårt API med latitud- och longitudkoordinater, vilket inte skapar någon tvetydighet i vår resultatuppsättning. Parametrarna är avgång_lat, avgång_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.8777Om du omvandlar dina städer till platser och ställer en fråga baserad på koordinater, kommer vårt API att svara med alla restriktioner (på lands- och delstatsnivå) som är nödvändiga för att förstå resenärens avresa från avgångslandet och resa till destinationslandet.
För vissa typer av Entry Requirements kan det finnas extra associerade data i ett fält av metadatatyp som heter statister. Detta fält är en nyckel/värde-mappning av olika extra informationsbitar för ett visst krav.
Denna datainmatning omfattas av inmatningskravet typ 5. I detta inlägg statister mappning kommer att innehålla ett fält som heter karantän_dagar som kommer att innehålla ett heltal för antalet karantänsdagar som ålagts.
Denna datainmatning omfattas av inmatningskravet typ 8. I detta inlägg statister mappning kommer att innehålla ett fält som heter inmatning_timmar som kommer att innehålla ett heltal för det antal timmar som ett negativt covid-test tillåts före inresa.
Vi tror att vi har en mycket robust lösning som sannolikt kommer att tillgodose alla dina behov av att hjälpa dina resenärer att förstå vad de sannolikt kommer att stöta på längs vägen. Om du har ett särskilt användningsfall som vi inte tar upp, vänligen meddela oss!
Det här inlägget är en del av en serie i två delar som förklarar hur man interagerar med Sitata API för information om inresekrav och reserestriktioner. Hittills har vi pratat om inresekrav som beskriver de hårda ja/nej-krav 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 inne i landet. 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 flytta runt i landet eller besöka stränderna eller om det finns ett obligatoriskt utegångsförbud.
Håll ögonen öppna för det andra inlägget som kommer att djupdyka i vår datauppsättning för resebegränsningar. Tips - det är nästan identiskt så du kan alltid ta en titt på vår API-dokumentation under tiden.
English 
Español 
Français 
Italiano 
Deutsch 
Magyar 
Română 
العربية 
Polski 
Português 
Nederlands 
Svenska 
Suomi 
Norsk bokmål 
Dansk