Sådan bruger du Sitatas API'er til at bestemme rejserestriktioner for rejsende

Mange af jer ved det måske ikke, men de første grundsten i Sitata blev lagt for tidlig sygdomsopdagelse. Faktisk har vores grundlægger et TedX-foredrag fra 2016 om hvorfor vi har brug for at advare rejsende for at hjælpe med at forhindre sygdomsspredning. Det bør derfor ikke komme som en overraskelse, at vi hørte om COVID-19, da der blev rapporteret om et usædvanligt klynge af lungebetændelsestilfælde i begyndelsen af december 2019. Den 2. januar 2020 besluttede vores sundhedsteam, at vi skulle udsende vores første advarsel til vores rejsende og forretningspartnere. Dette var dage før selv Verdenssundhedsorganisationen!

Under den uundgåelige efterspil fik vi en åbenbaring. Sygdommen spredte sig så hurtigt, at det var klart for os, at den globale reaktion i bedste fald ville være kaotisk. Hvert land ville indføre sit eget sæt af regler og forskrifter for at kontrollere spredningen. Dette ville uundgåeligt skabe kaos i den globale rejseaktivitet og være en enorm kilde til forvirring for dem, der stadig ønskede at rejse. Vi havde ret, og vi besluttede os for at gøre noget ved det. Sitata var et af de første virksomheder i verden til at skabe et dedikeret API og overvågningstjeneste for ændringer i rejserestriktioner og indrejsekrav som følge af COVID-19. Med et avanceret software-system til hændelsesopdagelse og et dedikeret team af analytikere havde vi allerede alle de rigtige værktøjer og processer til at gøre det.

Siden lanceringen af denne nye tjeneste har vi haft en række organisationer, der udnytter dataene til fordel for deres egne kunder, herunder Eddy Travels, Flight Centre og Etihad Airways; og der er flere, der snart vil blive annonceret! For at hjælpe flere rejsefokuserede organisationer med at drage fordel af dette tilbud, har vi nedenfor skrevet i detaljer en række eksempler for at hjælpe med at forklare, hvordan man bruger API’et til en række forskellige use cases. Jeg håber, at disse forklaringer vil hjælpe dig med at komme i gang med dine egne initiativer.

Indrejsekrav

Uden tvivl er de første spørgsmål, en rejsende stiller, “kan jeg komme derhen?” og “bliver jeg sat i karantæne?”, så det er et godt sted at starte. Vi har oprettet datasættet Indrejsekrav for at besvare de hårde “ja/nej”-spørgsmål vedrørende indrejse til et land eller en region.

På tidspunktet for udarbejdelsen af dette indlæg inkluderede dette datasæt følgende 10 forskellige kategorier:

• Kan en beboer komme ind i landet?
• Kan en udlænding komme ind i landet?
• Er transit gennem landet tilladt?
• Er en test ved ankomst påkrævet (sygdomsudbrud)?
• Er et testcertifikat tilladt (sygdomsudbrud)?
• Er karantæne ved ankomst påkrævet (sygdomsudbrud)? Er vaccine påkrævet?
• Er forsikring påkrævet?
• Er et testcertifikat påkrævet?
• Er et registreringsskema påkrævet? (sundhed eller andet)

Hver kategori kan have en af følgende værdier:

• Ja
• Ja, med undtagelser
• Nej
• Nej, med undtagelser

Selvom langt de fleste værdier er “ja” og “nej”, er situationen på jorden ikke altid så ligetil. Nogle gange er der virkelig mærkelige og vanvittige regler, som forskellige regeringer har indført, der kræver “med undtagelser”-typerne af værdier.

Et indrejsekrav er i bund og grund en post, der dokumenterer et sæt regler pålagt af en aktør mod et eller flere lande eller regioner. Aktøren kunne være et land, en stat eller endda en kommune i vores datastruktur. Generelt dækker Sitata data på landsniveau i øjeblikket. Vi har dog nogle stats-/provinsniveau-poster for udvalgte regioner som USA og andre.

Enhver post, der har en værdi i feltet **origin_country_division_id** eller **origin_country_region_id**, er henholdsvis på stats- eller kommuneniveau. Hvis du ønsker mere detaljerede data, så kontakt os venligst, så kan vi drøfte din use case.

Tag dig tid til at sætte dig ind i datastrukturen for indrejsekrav ved at kigge på vores API-dokumentation her.

Et lidt forvirrende aspekt ved datastrukturen er vores brug af udtrykket “origin” (oprindelse). Dette er forvirrende, fordi udviklere ofte tror, at oprindelsen er afrejsestedet eller udgangspunktet. Men hvad vi mener med oprindelse er faktisk oprindelsen til den regel, der pålægges andre, dvs. det land eller den region, der har oprettet restriktionen.

Et andet vigtigt punkt at bemærke er, hvordan vores liste over berørte lande fungerer. Hvis affected_countries er tom, skal det fortolkes som en global regel, dvs. alle lande er berørte.

Nogle eksempler

Som du måske har set i dokumentationen, er der flere måder at hente data fra API’et på. Nedenfor gennemgår vi nogle af de mest almindelige use cases.

Hvordan får jeg kravene mellem to lande?

Der er et par måder at lave denne type forespørgsel på. Den enkleste version er at bruge parametrene **destination** og **departure**. Disse parametre accepterer ISO 3166-1 alfa-2-koder som input.

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

Svaret vil inkludere alle krav (på lands- og statsniveau), som er nødvendige at forstå for den rejsende, der afrejser fra afrejselandet og rejser til destinationslandet.

Hvad hvis jeg vil have data på statsniveau?

Sitata har data på statsniveau for visse regioner. Du vil vide, at en bestemt post er for en stat, hvis feltet origin_country_division_id har en værdi. Du kan også filtrere for kun at hente data på statsniveau ved at bruge parameteren **destination_country_division**. Den forventer en ISO_3166-2-værdi. For eksempel US-TX for Texas, USA.

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

Bemærk, at det kan være enklere at forespørge på landsniveau og derefter filtrere efter statsdata for at se, om disse data findes, og bruge dem, hvis de gør.

Hvordan får jeg kravene mellem to lufthavne?

Ligesom med lande kan Sitatas API returnere resultater mellem to lufthavne. Parametrene departure_airport og destination_airport bruger ICAO- eller IATA-koder til at filtrere resultaterne. Svaret vil inkludere alle restriktioner (på lands- og statsniveau), der er nødvendige at forstå for den rejsende, der afrejser fra det tilsvarende afrejseland og rejser til destinationslandet.

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

Svaret vil inkludere alle restriktioner (på lands- og statsniveau), der er nødvendige at forstå for den rejsende, der afrejser fra afrejselandet og rejser til destinationslandet.

Hvad hvis jeg kun har byoplysninger?

Sitata valgte ikke at understøtte forespørgsler baseret på et bestemt bynavn, fordi det kunne føre til konflikter og forvirring. I stedet valgte vi at understøtte forespørgsler til vores API baseret på bredde- og længdegradskoordinater, hvilket ikke skaber nogen tvetydighed i vores resultatsæt. Parametrene 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 omdanner dine byer til lokationer og forespørger baseret på koordinaterne, vil vores API svare med alle restriktioner (på lands- og statsniveau), der er nødvendige at forstå for den rejsende, der afrejser fra afrejselandet og rejser til destinationslandet.

Yderligere data

For nogle typer af indrejsekrav kan der være yderligere data tilknyttet i et metadatafelt af typen kaldet extras. Dette felt er en nøgle/værdi-mapping af forskellige ekstra informationer for et bestemt krav.

Hvor mange dage er karantænen?

Denne datapost er underlagt indrejsekrav type 5. I denne post vil **extras**-mappingen indeholde et felt kaldet quarantine_days, der vil indeholde et heltal for antallet af pålagte karantænedage.

Hvor mange timer før indrejse for en negativ covid-test?

Denne datapost er underlagt indrejsekrav type 8. I denne post vil **extras**-mappingen indeholde et felt kaldet entry_hours, der vil indeholde et heltal for antallet af timer, en negativ covid-test er tilladt før indrejse.

Fortæl os

Vi mener, at vi har et meget robust API, der sandsynligvis opfylder alle dine behov for at hjælpe dine rejsende med at forstå, hvad de sandsynligvis vil støde på undervejs. Hvis du har en specifik use case, som vi ikke dækker, så fortæl os det venligst!

Vent… der er mere!

Dette indlæg er del 1 af en to-dels serie, der forklarer, hvordan man interagerer med Sitatas API for indrejsekrav og information om rejserestriktioner. Indtil videre har vi talt om Indrejsekrav, som skitserer de hårde ja/nej-typer af krav, der er nødvendige for at komme ind i et land eller en region, men vi har ikke talt om, hvad der sker inden i landet. Det er én ting at vide om indrejse til et land, og noget andet at forstå, om det er muligt at bevæge sig rundt i landet eller besøge strande, eller om der er en obligatorisk udgangsforbud.

Hold øje med det andet indlæg, der vil dykke ned i vores Rejserestriktion-datasæt. Hint - det er næsten identisk, så du kan altid tage et kig på vores API-dokumentation i mellemtiden.