What is an API? – Application Programming Interface

If you’re not in the know about APIs, you might be surprised to hear that you are likely using an API every day without realising it!

In short, an API is an interface that allows two applications to share information with each other.

So, how does an API work?

Here’s an example –

You’ve just headed over to aviowiki’s free access aviation data hub in search for airport information.

When you enter the name or ICAO of the airport and hit send, a request is sent to the aviowiki API asking the question.

The API searches and pulls that all important airport data from the database and displays it to you in a customised and easy to read format.

Simple, right?

But that’s not all you can do with an API

An API is flexible. Not only can you retrieve information from a database, you can also replace, add and delete information which is what gives us the ability to accept updates from our users across the world – You should give it a try, its free! 

And, there’s more!

aviowiki’s API and our fully machine-readable data can be used creatively. With countless ways to read, share and distribute our aviation data, the possibilities to improve your business and processes are endless.

You can choose which of our extensive and continually updated datasets you would like to use and we can even create new sets data, for complete personalisation, geared towards your business requirements.

Need to integrate ATC availability into your software? Create a simple interface showing customs information at your 10 favourite airports? or perhaps display an automated alert when an airport is closed?

All of this can be created with the easiest API.

Head over to aviowiki and start powering your business with our API and aviation data today.

Digitising exceptions, to automate more.

We talk about this all the time: an industry cannot be automated until it is digitised. This is why aviowiki exists, to digitise aviation so that all the cool automated things can work.

In digitising any information we first need to have a good idea of what problem we want to solve. Based on that, we can then specify what data we need and then go on to decide how to extract it from the information source.

For complex things, like airport opening hours, we had to make certain choices in the beginning of our journey. One of these choices was to fully rely on human intervention to manage airport opening hours exceptions. This means that for any specific point in time, the airport and its services (ARFF, ATC, and Customs), could be either “Open”, “Closed”, or “Limited”.

In the case of “Open” or “Closed” the situation was clear: either a clear go-ahead or a clear show-stopper. With “Limited” we always included a free-text note that would explain all limitations. This is what we would recommend our customers to show to a human to make a decision.

For the gurus of aviation digitisation, this started not to be enough. So here we are, expanding our data model to bridge that gap and make “Limited” machine readable.

How did we do this? Go on, keep reading!

Who is the airport open for?

In simple terms, all of the Limited opening hours meant that there were some conditions to be met for aircraft to use the airport. Usually these looked something like “Available only for Medevac, SAR, Ambulance, and State flights”. In some cases we had exceptions like “Available with 6h PNR, for a fee”.

So after analysing a few hundred cases, we decided that the best thing to do to cover most scenarios of Limited opening hours, was to create a data model to specify who the airport is open for. So enter our ‘openFor’ property!

Whenever an airport availability block has status of “Limited” we now have the possibility of including a list of exceptions for which the airport can be considered open, in the new ‘openFor’ property of the availability block. Each element in the list describes what types of flight can access the airport, and under what condition, if any particular.

For example, we can now specify that at a certain time only scheduled airline flights can operate, or that all VFR flights require 3 hours notice, or again that during a night closure the airport remains available to Hospital and SAR flights.

We can describe each case accurately, using an extensive digital model that draws inspiration from ICAO’s Doc 4444 in the way it classifies a flight. Additionally we can also say if a prior notice is required to operate such flight, and if any extra cost is involved.

Why go in such details?

Well, this goes back to the initial point: there’s no automation without digitisation.

Aviation is an industry made of exceptions. There are exceptions possible to all sort of rules. And Airports operations are no… exception!

So it makes total sense to us to dive deeper in the complexities of the Airport opening hours, and digitise more and more special cases. By doing this we enable more automation. Our customers’ systems are able to handle more scenarios without having to raise exceptions to humans, which makes a stronger case for the adoption of digital data.

What’s next?

Our goal is to digitise everything, so we’ll certainly continue to iterate on this model, expand it and refine it. But we will not stop there!

We’re constantly poked with questions like “do you also have this information”? And we certainly draw a lot of ideas from conversations with our customers. So perhaps you can help us here. What’s bothering you today? What process you cannot automate because the data is not there yet?

Be sure to let us know by writing to hello@aviowiki.com, LinkedIn, or Twitter.

And if you don’t want to miss a beat of our innovations, please consider subscribing to our newsletter. We’re very sensible and won’t spam your inbox.

Stay hungry

with our newsletter