Hvordan bruke Sitata sine API-er for å fastslå reiserestriksjoner for reisende

Mange av dere vet kanskje ikke dette, men de første grunnsteinene i Sitata ble lagt for tidlig sykdomsoppdagelse. Vår gründer har faktisk en TedX-tale fra 2016 om hvorfor vi må advare reisende for å hindre spredning av sykdom. Det bør derfor ikke komme som noen overraskelse at vi fikk kjennskap til COVID-19 da det ble rapportert om et uvanlig klynge av lungebetennelsestilfeller tidlig i desember 2019. Den 2. januar 2020 bestemte vårt helseteam at vi skulle utstede vår første advarsel til våre reisende og forretningspartnere. Dette var dager før selv Verdens helseorganisasjon!

Under den uunngåelige etterspillet hadde vi en åpenbaring. Sykdommen spredte seg så raskt at det var klart for oss at den globale responsen i beste fall ville bli kaotisk. Hvert land ville innføre sitt eget sett med reguleringer og regler for å kontrollere spredningen. Dette ville uunngåelig skape kaos for global reisevirksomhet og være en enorm kilde til forvirring for de som fremdeles ønsket å reise. Vi hadde rett, og vi bestemte oss for å gjøre noe med det. Sitata var et av de første selskapene i verden som skapte et dedikert API og overvåkningstjeneste for endringer i reiserestriksjoner og innreiseregler som følge av COVID-19. Med et avansert programvaresystem for hendelsesdeteksjon og et dedikert team av analytikere, hadde vi allerede alle de riktige verktøyene og prosessene for å gjøre det.

Siden lanseringen av denne nye tjenesten har vi hatt en rekke organisasjoner som benytter seg av dataene til fordel for sine egne kunder, inkludert Eddy Travels, Flight Centre og Etihad Airways; og flere vil bli kunngjort snart! For å hjelpe flere reiserettede organisasjoner med å dra nytte av dette tilbudet, har vi nedenfor skrevet i detalj en rekke eksempler for å forklare hvordan man bruker API-et for ulike brukstilfeller. Jeg håper disse forklaringene hjelper deg med å komme i gang med dine egne initiativer.

Innreisekrav

De første spørsmålene en reisende stiller er uten tvil “kan jeg dra dit?” og “blir jeg satt i karantene?”, så dette er et godt sted å starte. Vi har opprettet Innreisekrav-datasettet for å svare på de harde “ja/nei”-spørsmålene knyttet til innreise til et land eller en region.

På tidspunktet for skriving inkluderte dette datasettet følgende 10 distinkte kategorier:

• Kan en innbygger komme inn i landet?
• Kan en utlending komme inn i landet?
• Er gjennomreise gjennom landet tillatt?
• Kreves test ved ankomst (sykdomsutbrudd)?
• Er testattest tillatt (sykdomsutbrudd)?
• Kreves karantene ved ankomst (sykdomsutbrudd)? Kreves vaksine?
• Kreves forsikring?
• Kreves testattest?
• Kreves registreringsskjema? (helse eller annet)

Hver kategori kan ha en av følgende verdier:

• Ja
• Ja, med unntak
• Nei
• Nei, med unntak

Selv om de aller fleste verdiene er “ja” og “nei”, er situasjonen på bakken ikke alltid så enkel. Noen ganger er det virkelig rare og sprø regler som ulike regjeringer har innført som krever “med unntak”-verdiene.

Et innreisekrav er i bunn og grunn en post som dokumenterer et sett med regler pålagt av en aktør mot ett eller flere land eller regioner. Aktøren kan være et land, en stat eller til og med en kommune i vår dataarkitektur. Generelt dekker Sitata data på landsnivå for øyeblikket. Imidlertid har vi noen statlige/provinsielle poster for utvalgte regioner som USA og andre.

Enhver post som har en oppføring under feltet **origin_country_division_id** eller **origin_country_region_id** er henholdsvis på statlig eller kommunalt nivå. Hvis du ønsker mer detaljerte data, vennligst ta kontakt med oss så kan vi diskutere ditt brukstilfelle.

Ta deg tid til å bli kjent med datastrukturen for innreisekrav ved å se på våre API-dokumenter her.

Et litt forvirrende aspekt ved datastrukturen er vår bruk av begrepet “origin” (opprinnelse). Dette er forvirrende fordi utviklere ofte tenker at opprinnelse er stedet man reiser fra. Imidlertid er det vi mener med opprinnelse faktisk kilden til regelen som pålegges andre, det vil si landet eller regionen som har opprettet restriksjonen.

Et annet viktig poeng å merke seg er hvordan vår liste over berørte land fungerer. Hvis affected_countries er tom, skal det tolkes som en global regel, dvs. alle land er berørt.

Noen eksempler

Som du har sett i dokumentasjonen, er det flere måter å hente data fra API-et på. Nedenfor ser vi på noen av de vanligste brukstilfellene.

Hvordan får jeg kravene mellom to land?

Det er et par måter å gjøre denne typen forespørsel på. Den enkleste versjonen er å bruke parametrene **destination** og **departure**. Disse parameterne aksepterer ISO 3166-1 alfa-2-koder som inndata.

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

Responsen vil inkludere alle krav (på lands- og statsnivå) som er nødvendige å forstå for reisenden som reiser fra avreiselandet til destinasjonslandet.

Hva med hvis jeg vil ha data på statsnivå?

Sitata har data på statsnivå for visse regioner. Du vil vite at en bestemt oppføring gjelder for en stat hvis feltet origin_country_division_id har en verdi. Du kan også filtrere for kun å hente data på statsnivå ved å bruke parameteren **destination_country_division**. Den forventer en ISO_3166-2-verdi. For eksempel US-TX for Texas, USA.

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

Merk at det kan være enklere å spørre etter land og deretter filtrere etter statdata for å se om disse dataene finnes, og bruke dem hvis de gjør det.

Hvordan får jeg kravene mellom to flyplasser?

Akkurat som med land, kan Sitata sitt API returnere resultater mellom to flyplasser. Parametrene departure_airport og destination_airport bruker ICAO- eller IATA-koder for å filtrere resultatene. Responsen vil inkludere alle restriksjoner (på lands- og statsnivå) som er nødvendige å forstå for reisenden som reiser fra det tilsvarende avreiselandet til destinasjonslandet.

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

Responsen vil inkludere alle restriksjoner (på lands- og statsnivå) som er nødvendige å forstå for reisenden som reiser fra avreiselandet til destinasjonslandet.

Hva med hvis jeg bare har byinformasjon?

Sitata valgte å ikke tilrettelegge for spørringer ved et spesifikt bynavn fordi det kunne føre til konflikter og forvirring. I stedet valgte vi å tilrettelegge for spørringer til vårt API ved bredde- og lengdegradskoordinater, noe som ikke produserer noen tvetydighet i vårt resultatsett. Parameterne er departure_lat, departure_lng, destination_lat og 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

Hvis du løser byene dine til lokasjoner og spørrer basert på koordinatene, vil vårt API svare med alle restriksjoner (på lands- og statsnivå) som er nødvendige å forstå for reisenden som reiser fra avreiselandet til destinasjonslandet.

Tilleggsdata

For noen typer innreisekrav kan det være tilknyttet tilleggsdata i et metadatafelt av typen extras. Dette feltet er en nøkkel/verdi-mapping av diverse ekstra informasjonsbiter for et spesifikt krav.

Hva er antall dager med karantene?

Denne dataoppføringen gjelder for innreisekrav type 5. I denne oppføringen vil **extras**-mappingen inneholde et felt kalt quarantine_days som vil inneholde et heltall for antall pålagte karantenedager.

Hva er antall timer før innreise for en negativ covid-test?

Denne dataoppføringen gjelder for innreisekrav type 8. I denne oppføringen vil **extras****-mappingen inneholde et felt kalt **entry_hours`** som vil inneholde et heltall for antall timer en negativ covid-test er gyldig før innreise.

Gi oss beskjed

Vi tror vi har et svært robust API som sannsynligvis dekker alle dine behov for å hjelpe dine reisende med å forstå hva de sannsynligvis vil møte på veien. Hvis du har et spesifikt brukstilfelle vi ikke dekker, gi oss beskjed!

Vent… det er mer!

Denne oppføringen er del én av en to-delt serie som forklarer hvordan man samhandler med Sitata sitt API for innreisekrav og informasjon om reiserestriksjoner. Så langt har vi snakket om Innreisekrav som skisserer de harde ja/nei-typene krav som er nødvendige for å komme inn i et land eller en region, men vi har heller ikke snakket om hva som skjer innenfor landet. Det er én ting å vite om innreise til et land, og en annen å forstå om det er mulig å bevege seg rundt i landet eller besøke strendene, eller om det er påbudt portforbud.

Følg med i del to som vil dykke ned i vårt Reiserestriksjon-datasett. Hint – det er nesten identisk, så du kan alltid ta en titt på vår API-dokumentasjon i mellomtiden.