Many of you might not know this, but Sitata’s early foundations were built for early disease detection. In fact, our founder has a TedX talk from 2016 all about why we need to warn travellers to help prevent the spread of disease. It should come as no surprise then that we picked up on COVID-19 when it was reported as an unusual cluster of cases of pneumonia early in December 2019. By January 2nd, 2020, our health team determined that we should issue our first warning to our travellers and business partners. This was days before even the World Health Organization!

During the inevitable fallout we had an epiphany. The disease was spreading so fast that it was clear to us the global response would be chaotic at best. Every country would enact its own set of regulations and rules for how to control the spread. This would inevitably wreak havoc on global travel and be a huge source of confusion for those that still wish to travel. We were right and we set out to do something about it. Sitata was one of the first companies in the world to create a dedicated API and monitoring service for the changes in travel restrictions and entry requirements as a result of COVID-19. With an advanced software system for event detection and a dedicated team of analysts, we already had all of the right tools and processes in place to do so.

Since launching this new service we have had a variety of organizations take advantage of the data for the benefit of their own customers including Eddy Travels, Flight Centre, and Etihad Airways; and there are more to be announced soon! In order to help more travel focused organizations benefit from this offering, we’ve written in detail below a number of examples to help explain how to use the API for a variety of use cases. I hope these explanations help you get your own initiatives off the ground.

Entry Requirements

Without question, the first questions a traveller ask are “can I go there?” and “will I be quarantined” and so this is a good place to start. We created the Entry Requirements data set to answer the hard “yes/no” types of questions concerning entering a country or region.

At the time of writing, this data set included the following 10 distinct categories:

• Can a resident enter the country?
• Can a foreigner enter the country?
• Is transit allowed through the country?
• Is a test required on arrival (disease outbreak)?
• Is a test certificate allowed (disease outbreak)?
• Is quarantine required on arrival (disease outbreak)? Is a vaccination required?
• Insurance required?
• Test certificate required?
• Entry form required? (health or other)

Each category can have one of the following values:

• Yes
• Yes, with exceptions
• No
• No, with exceptions

While the vast majority of the values are “yes” and “no”, the situation on the ground isn’t always so straightforward. Sometimes there are really weird and crazy rules that various governments have put into place which necessitates the value types “with exceptions.”

An Entry Requirement is essentially a record documenting a set of rules imposed by an actor against one or multiple other countries or regions. The actor could be a country, state, or even municipality in our data architecture. By and large, Sitata covers country-level data currently. However, we do have some state/provincial records for select regions such as the United States and others.

Any record that has an entry under the field origin_country_division_id or origin_country_region_id is one that is either state or municipal level, respectively. If you would like more granular data available, please contact us and we can talk about your use case.

Please take some time to familiarize yourself with the Entry Requirement data structure by having a look at our API docs here.

One slightly confusing part about the data structure is our use of the term “origin.” This is confusing because often developers think about origin as being the place of origin or place of departure. However, what we mean by origin is actually the origin of the rule imposed onto others. i.e. the country or region that has created the restriction.

Another important point to note is how our affected counntries list works. If affected_countries is empty, it should be interpreted as a global rule. i.e. all countries are affected.

A Few Examples

As you might have seen from the documentation, there are a number of ways to retrieve data from the API. Below we’ll walk through a few of the more common use cases.

How do I fetch the requirements between two countries?

There are a couple of ways to do this type of request. The simplest version is to use the destination and departure parameters. These parameters accept ISO 3166-1 alpha-2 codes as inputs.

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

The response will include all requirements (country and state level) necessary to understand for the traveller departing from the departure country and travelling to the destination country.

What if I want state-level data?

Sitata does have state-level data for certain regions. You will know a particular entry is for a state if the origin_country_division field has a value. You can also filter to only retrieve state level data using the destination_country_division parameter. It expects a ISO_3166-2 value. For example, US-TX for Texas, United states.

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

Note that it might be simpler to query by country and then filter by state data to see if such data exists, and use it if it does exist.

How do I fetch the requirements between two airports?

Just like with countries, the Sitata API can return results between two airports. The parameters departure_airport and destination_airport use either ICAO or IATA codes to filter the results. The response will include all restrictions (country and state level) necessary to understand for the traveller departing from the corresponding departure country and travelling to the destination country.

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

The response will include all restrictions (country and state level) necessary to understand for the traveller departing from the departure country and travelling to the destination country.

What if I only have city information?

Sitata chose not to accommodate queries by a particular city name because that could result in conflicts and confusion. Instead, we chose to accommodate querying our API by latitude and longitude coordinates which does not produce any ambiguity in our result set. The parameters are departure_lat, departure_lng, destination_lat, and 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

If you resolve your cities to locations and query based on coordinates, our API will respond with all restrictions (country and state level) necessary to understand for the traveller departing from the departure country and travelling to the destination country.

Extra Data

For some types of Entry Requirements, there may be extra associated data in a metadata type field called extras. This field is a key/value mapping of various extra bits of information for a particular requirement.

What is the number of days of quarantine?

This data entry falls under the entry requirement type 5. In this entry, the extras mapping will contain a field called quarantine_days which will contain an integer for the number of days of quarantine imposed.

What is the number of hours before entry for a negative covid test?

This data entry falls under the entry requirement type 8. In this entry, the extras mapping will contain a field called entry_hours which will contain an integer for the number of hours that a negative covid test is allowed prior to entry.

Let us know

We think we have a very robust that will likely address all of your needs to help your travellers understand what they’re likely to encounter along the way. If you have a particular use case that we’re not addressing, please let us know!

Wait… there’s more!

This entry is part of a two part series that explains how to interact with the Sitata API for Entry Requirements and Travel Restriction information. So far we’ve talked about Entry Requirements which outline the hard yes/no types of requirements necessary to enter a country or region, but we haven’t talked about what’s happening inside the country either. It’s one thing to know about going into a country, it’s another to understand if it’s possible to move around in the country or visit the beaches or if there’s a mandatory curfew.

Stay tuned for the second post that will deep-dive into our Travel Restriction data set. Hint – it’s nearly identical so you can always have a look at our API documentation in the meantime.

Please follow and like us: