Sådan bruger du Sitatas API'er til at bestemme rejsebegrænsninger for rejsende

Mange af jer ved det måske ikke, men Sitatas tidlige fundament blev bygget til tidlig sygdomsopdagelse. Faktisk har vores grundlægger et TedX-foredrag fra 2016 om hvorfor vi er nødt til at advare rejsende for at hjælpe med at forhindre spredning af sygdom. Det bør derfor ikke komme som nogen overraskelse, at vi opdagede COVID-19, da det blev rapporteret som en usædvanlig klynge af lungebetændelsestilfælde tidligt i december 2019. Den 2. januar 2020 besluttede vores sundhedshold, at vi skulle udsende vores første advarsel til vores rejsende og forretningspartnere. Dette var dage før selv Verdenssundhedsorganisationen!

Under den uundgåelige krise 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 for den globale rejseaktivitet og være en enorm kilde til forvirring for dem, der stadig ønsker at rejse. Vi havde ret, og vi besluttede at gøre noget ved det. Sitata var et af de første virksomheder i verden, der skabte et dedikeret API og overvågningstjeneste for ændringer i rejsebegrænsninger og indrejsekrav som følge af COVID-19. Med et avanceret softwaresystem til hændelsesdetektering og et dedikeret hold af analytikere havde vi allerede alle de rigtige værktøjer og processer på plads til at gøre det.

Siden lanceringen af denne nye tjeneste har en række organisationer draget fordel af dataene til gavn 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 rejseorienterede organisationer med at drage fordel af dette tilbud, har vi nedenfor skrevet i detaljer en række eksempler for at forklare, hvordan man bruger API’et til forskellige brugsscenarier. Jeg håber, disse forklaringer hjælper dig med at få dine egne initiativer i gang.

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 skabte datasættet Indrejsekrav for at besvare de klare “ja/nej”-typer af spørgsmål vedrørende indrejse til et land eller en region.

På tidspunktet for skrivning 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 påkrævet ved ankomst (sygdomsudbrud)?
• Er et testbevis tilladt (sygdomsudbrud)?
• Er karantæne påkrævet ved ankomst (sygdomsudbrud)? Er vaccination påkrævet?
• Forsikring påkrævet?
• Testbevis påkrævet?
• Indrejseformular påkrævet? (sundhedsrelateret eller andet)

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

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

Mens langt de fleste værdier er “ja” og “nej”, er situationen på jorden ikke altid så ligetil. Nogle gange er der virkelig underlige og vanvittige regler, som forskellige regeringer har indført, hvilket nødvendiggør værdityperne “med undtagelser.”

Et Indrejsekrav er i bund og grund en post, der dokumenterer et sæt regler pålagt af en aktør over for et eller flere andre lande eller regioner. Aktøren kan være et land, en stat eller endda en kommune i vores dataarkitektur. I det store og hele dækker Sitata i øjeblikket data på landsniveau. Vi har dog nogle stats-/provinsdata for udvalgte regioner som f.eks. USA og andre.

Enhver post, der har en indtastning under feltet **origin_country_division_id** eller **origin_country_region_id**, er enten på stats- eller kommuneniveau. Hvis du ønsker mere detaljerede data tilgængelige, bedes du kontakte os, så kan vi tale om dit brugsscenarie.

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

Et lidt forvirrende aspekt ved datastrukturen er vores brug af udtrykket “origin.” Dette er forvirrende, fordi udviklere ofte tænker på “origin” som oprindelsesstedet eller afrejsestedet. Men det, vi mener med “origin,” er faktisk oprindelsen af den regel, der pålægges andre, dvs. det land eller den region, der har skabt begrænsningen.

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.

Et par 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 et par af de mere almindelige brugsscenarier.

Hvordan henter jeg kravene mellem to lande?

Der er et par måder at lave denne type anmodning på. Den enkleste version er at bruge parametrene **destination** og **departure**. Disse parametre accepterer ISO 3166-1 alpha-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 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 efter land og derefter filtrere efter statsdata for at se, om sådanne data findes, og bruge dem, hvis de eksisterer.

Hvordan henter jeg kravene mellem to lufthavne?

Ligesom med lande kan Sitata API returnere resultater mellem to lufthavne. Parametrene departure_airport og destination_airport bruger enten ICAO- eller IATA-koder til at filtrere resultaterne. Svaret vil inkludere alle begrænsninger (på lands- og statsniveau), som 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 begrænsninger (på lands- og statsniveau), som er nødvendige at forstå for den rejsende, der afrejser fra afrejselandet og rejser til destinationslandet.

Hvad hvis jeg kun har byinformation?

Sitata valgte ikke at understøtte forespørgsler efter et bestemt bynavn, fordi det kunne resultere i konflikter og forvirring. I stedet valgte vi at understøtte forespørgsel til vores API ved hjælp af bredde- og længdegradskoordinater, som 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å koordinater, vil vores API svare med alle begrænsninger (på lands- og statsniveau), som er nødvendige at forstå for den rejsende, der afrejser fra afrejselandet og rejser til destinationslandet.

Ekstra data

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

Hvad er antallet af karantænedage?

Denne dataentry falder under indrejsekrav type 5. I denne post vil **extras**-mappingen indeholde et felt kaldet quarantine_days, som vil indeholde et heltal for antallet af pålagte karantænedage.

Hvad er antallet af timer før indrejse for en negativ covid-test?

Denne dataentry falder under indrejsekrav type 8. I denne post vil **extras**-mappingen indeholde et felt kaldet entry_hours, som vil indeholde et heltal for antallet af timer, en negativ covid-test er gyldig før indrejse.

Fortæl os det

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

Vent… der er mere!

Dette indlæg er del af en to-dels serie, der forklarer, hvordan man interagerer med Sitata API’et for Indrejsekrav og Rejsebegrænsningsinformation. Indtil videre har vi talt om Indrejsekrav, som skitserer de klare 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 inde i landet. Det er én ting at vide om indrejse til et land, det er en anden at forstå, om det er muligt at bevæge sig rundt i landet eller besøge strandene, eller om der er udgangsforbud.

Hold øje med det andet indlæg, som vil dykke dybt ned i vores Rejsebegrænsnings-datasæt. Hint - det er næsten identisk, så du kan altid kigge på vores API-dokumentation i mellemtiden.