API

What Researchers
Need To Know

Many less-technically-minded professionals have a vague or incorrect idea about what an API means, what it can do, and even less how it works. This knowledge could be highly beneficial for professional market researchers who typically work with many specialized programs and large chunks of data. So, read on and immerse yourself into the basics of an API.

API facilitates data processing and monotonous tasks

API, which stands for Application Programming Interface, is a bridge that connects two completely different programs (e.g. Adobe Analytics reports with Microsoft Excel or a company’s website form with an employee’s Google calendar). When two programs link up through an API, we say they are integrated.

The integration enables you to move data back and forth from one program to another in order to automate, facilitate and quicken data analysis processes and other tasks. The benefits are clear: you can forget all the manual, repetitive and laborious tasks and focus on the more fruitful tasks such as client meetings and data insights instead!

When properly applied, API is a powerful shortcut for business workloads.

Its use is widespread replacing older, time-consuming methods of data collection. Typically, it serves to:
  • automate repetitive tasks.
  • execute actions without entering the program’s interface.
  • retrieve large chunks of data rapidly.
  • tailor and automate reporting to specific requirements.

Once the desired API workflow is set up, it will save an enormous amount of time for marketers, researchers, data analysts and other professionals.

API is an open gate to a program

Now you know what API can do in general. But what does it look like? And how does it work in Nfield?

The API is a direct command that was built by the developers of the program that collects the data you need. It can look for example like this: v1/Surveys/{surveyId}/Fieldwork/Start.

NOTE: The command can take different forms, of which the easiest for beginners to understand is a complete URL command, that looks like this example from Nfield:
https://api.nfieldmr.com/v1/Surveys/{surveyId}/Fieldwork/Start.

Simply speaking, there are two very good reasons why developers spend time on building this type of command. Let’s have a closer look at them:
  • The code isn’t usually exposed
    The work of developers is to ensure the program’s integrity and reliable functions for its users. So that you (= user) will never experience the nightmare of logging into your favorite program, only to find that it has crashed and you’re unable to do necessary work. This, for example, includes developers precluding an unauthorized manipulation of the code, which would be likely to cause you problems when using the program. It’s also important to remember that the code is a business asset that is usually protected by copyright.
  • The code needs to be exposed
    On the other hand, the closed program doesn’t benefit its users. It’s certainly true that you need a reliable program, but that’s not where it ends. For you also often need a program that can be plugged into another program, enabling you to create smart and fast integrated workloads and making your day-to-day tasks much easier.

So here’s how it’s done:

Instead of uncovering a program’s code completely, developers decide which endpoints of the code can be exposed and then build open gates to them. Those gates are commands (or APIs if you like) through which another program is able to plug in.

When a command is applied with a click on the button or command key, it either retrieves the data you request or sends in the data you need to submit, while the program’s functions and code remain reliable and intact.

APIs technical minimum: parameters and log-in

Without getting too technical and exceeding the scope of these rather general explanations, whether or not you would like to try API yourself, there are two technicalities that you may find useful to know when discussing API with your colleagues.

The first is that each command is programmed to perform one specific task. So, for example, one command will tell you instantly the number of addresses included in a sampling point, while another command will tell you the details of a single address.

CAPI surveys – command for the number of addresses in a sampling point:
v1/Surveys/{surveyId}/SamplingPoints/{samplingPointId}/Addresses/Count

CAPI surveys – command for the details of a single address:
v1/Surveys/{surveyId}/SamplingPoints/{samplingPointId}/Addresses/{addressId}


In other words, it’s not possible to use one command for everything. This entails three important points you should remember:
  • Each program usually comes with many commands.
  • The command cannot retrieve any other data, information or perform any other action than which it has been designed for.
  • You may find some commands lacking. These have yet to be developed.

The simple formula to remember is: one command equals one task.

But there is one more significant aspect to pinpoint: before using a command, more information, such as where or how many, needs to be defined to specify exactly what you want to happen. And that is what parameters are for.

BASICS The parameter is part of a command, usually displayed as {brackets} or ?questionmark.

So now let’s go back to our Nfield example of the number of addresses included in a sampling point.

Command: v1/Surveys/{surveyId}/SamplingPoints/{samplingPointId}/Addresses/Count

The command certainly knows what it is set to do: it has to go somewhere to count the addresses and return to you with the total number. But the command doesn’t know where to go to count. That is something you have to give by providing the name of a survey and the name of a sampling point in the form of parameters.

Command: v1/Surveys/{SurveyId}/SamplingPoints/{SamplingPointId}/Addresses/Count

You ask for: v1/Surveys/{AwarenessSurvey}/SamplingPoints/{sp24}/Addresses/Count


So now the command goes and counts the number of addresses in the Awareness Survey in the sampling point named sp24.

Voila!

The second technicality is that a list of APIs and usually also credentials are needed to log into a program’s API environment where they are to be applied. The API list is commonly available online. If not, then ask the program’s owner for it.

Obtaining the credentials is another formality. Many organizations will enable you to create credentials yourself, while others will provide you with credentials on demand when contacting their customer supports or account managers. And there are even URL commands that can be used directly by placing them into the address bar of browsers, in which case the credentials are not needed.

Start now

That’s everything or perhaps even more that an experienced research professional needs to know about API.

To some, this might sound daunting but it’s a straightforward task for any data analyst, scripter or developer. Actually, some API applications are so simple that a curious researcher can even learn it themself!

What’s next then?
  • Take the first step, and ask your colleagues today how APIs can automate your monotonous tasks. Find opportunities within your weekly project workloads and engage your developers to help you become time-efficient.
  • Take the next step, and learn more from our newsfeed 'Automation with Nfield' that can be found in the customer section of the NIPO website.

Get in touch

+31 (0) 20 5225 989 hello@nipo.com
Meet NIPO Team

NIPO News update

NIPO News update

Get notified when we publish new handy tips and important news about Nfield