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

Mange af jer ved det måske ikke, men de første grundsten i Sitata blev lagt for tidlig sygdomsopdagelse. Faktisk holdt vores grundlægger et TedX-foredrag tilbage i 2016 om hvorfor vi skal advare rejsende for at forhindre sygdomsudbredelse. Så det er ikke overraskende, at vi lærte om COVID-19, som blev rapporteret som en usædvanlig gruppe af lungebetændelsestilfælde i begyndelsen af december 2019. Den 2. januar 2020 besluttede vores sundhedshold, at vi skulle udsende et tidligt varsel til vores rejsende og forretningspartnere. Det var flere dage før end Verdenssundhedsorganisationen!

Under de uundgåelige eftervirkninger fik vi en åbenbaring. Sygdommen spredte sig så hurtigt, at det var klart for os, at den globale reaktion i bedste fald ville blive kaotisk. Hvert land ville indføre sine egne regler og forskrifter for at kontrollere spredningen. Det ville uundgåeligt skabe kaos på verdensplan og være en enorm kilde til forvirring for dem, der stadig ønskede at rejse. Vi havde ret, og vi besluttede at gøre noget ved det. Sitata var et af de første virksomheder i verden til at skabe et dedikeret API og en service til at spore ændringer i rejsebegrænsninger og indrejsebetingelser som følge af COVID-19. Takket være et avanceret softwarebaseret eventdetekteringssystem og et team af specialiserede analytikere havde vi allerede alle de værktøjer og processer, der var nødvendige for at gøre det.

Siden lanceringen af denne nye service har flere organisationer draget fordel af dataene til fordel for deres egne kunder, herunder Eddy Travels, Flight Centre og Etihad Airways; flere meddelelser kommer snart! For at hjælpe flere rejseorienterede organisationer med at drage fordel af dette tilbud, har vi nedenfor udførligt beskrevet en række eksempler for at forklare, hvordan man bruger API’et til forskellige brugsscenarier. Jeg håber, at disse forklaringer vil hjælpe dig i gang med dine egne initiativer.

Indrejsebetingelser

De første spørgsmål en rejsende utvivlsomt stiller, er: “Kan jeg komme ind?” og “Bliver jeg sat i karantæne?”, så det er et godt sted at starte. Vi skabte indrejsebetingelses-datasættet for at besvare de svære ja/nej-spørgsmål om indrejse til et land eller en region.

På tidspunktet for skrivning inkluderede dette datasæt følgende ti 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 (ved sygdom)?
• Er et testcertifikat tilladt (ved sygdom)?
• Er karantæne ved ankomst nødvendig (ved sygdom)?
• Er vaccination påkrævet?
• Er forsikring påkrævet?
• Er testcertifikat påkrævet?
• Er registreringsformular påkrævet? (sundhed eller andet)

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

• Ja
• Ja, med undtagelser
• Nej
• Nej, medmindre der er undtagelser

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

En indrejsebetingelse er i bund og grund et dokument, der beskriver et sæt regler pålagt af en aktør mod et eller flere andre lande eller regioner. Aktøren kan være et land, en stat eller endda en kommune i vores datastruktur. Overordnet set dækker Sitata i øjeblikket data på landsniveau. Vi har dog nogle få stat/provins-poster for visse regioner, som f.eks. USA og andre.

Enhver post med en indtastning i feltet **origin_country_division_id** eller **origin_country_region_id** er et niveau, der er henholdsvis på stats- eller kommuneniveau. Hvis du ønsker mere detaljerede data, så kontakt os venligst, så kan vi drøfte dit brugsscenarie.

Tag dig tid til at sætte dig ind i datastrukturen for indrejsebetingelser ved at se vores API-dokumentation her.

En del af datastrukturen er lidt forvirrende, nemlig vores brug af udtrykket “origin” (oprindelse). Denne forvirring opstår, fordi udviklere ofte betragter oprindelse som hjemstedet eller afrejsestedet. Men det, vi mener med “origin”, er faktisk oprindelsen til 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.

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 brugsscenarier.

Hvordan får man krav mellem to lande?

Der er flere måder at lave en sådan 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 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 søge efter et land og derefter filtrere dataene efter stat for at se, om disse data findes, og bruge dem, hvis de gør.

Hvordan får jeg krav mellem to lufthavne?

Ligesom med lande kan Sitata 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 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 information om byen?

Sitata har valgt ikke at besvare anmodninger om et bestemt bynavn, da det kan føre til konflikter og forvirring. I stedet har vi valgt at acceptere forespørgsler til vores API via bredde- og længdegradskoordinater, hvilket ikke skaber 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 opløser dine byer til steder og forespørger via 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.

Yderligere information

For visse typer af indrejsebetingelser kan der være tilknyttede yderligere data i et metadata-type felt kaldet extras. Dette felt er en nøgle/værdi-mapping af forskellige stykker ekstra information for et bestemt krav.

Hvor mange dages karantæne er der?

Denne dataindtastning er underlagt indrejsebetingelsestype 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.

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

Denne dataindtastning er underlagt indrejsebetingelsestype 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.

Lad os høre fra dig

Vi mener, at vi har et meget robust værktøj, der sandsynligvis vil opfylde 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å lad os det vide!

Vent… der er mere!

Dette indlæg er del af en to-dels serie, der forklarer, hvordan man interagerer med Sitata API for information om indrejsebetingelser og rejsebegrænsninger. Indtil videre har vi talt om indrejsebetingelser, som beskriver de strenge ja/nej-betingelser, der er nødvendige for at komme ind i et land eller en region, men vi har heller ikke talt om, hvad der sker inden i landet. Det er én ting at vide, hvordan man kommer ind i et land, det er en anden at forstå, om man kan bevæge sig rundt i landet eller besøge strande, eller om der er obligatorisk udgangsforbud.

Hold øje med den anden artikel, der vil dykke dybere ned i vores datasæt om rejsebegrænsninger. Hint: det er næsten identisk, så du kan altid tjekke vores API-dokumentation i mellemtiden.