Not all software has an API, but it’s increasingly an expectation for SaaS (Software-as-a-Service) products to provide an open API and thorough documentation for developers to build integrations. To use an API, an integration needs an API key, just as a human user has login details. Some platforms charge for API access, just as you might have to pay a monthly fee for each (human) user account.

An API key is a long, unique string of letters and numbers. It acts like the username and password that lets an integration access an API. It’s unique to your account and should be treated like any other piece of sensitive information that you use to log in to a private account online — never send an API key by email!

When we build an integration between two applications, we get the API keys for each app. Whenever one application sends an instruction to the other, that instruction includes the API key to verify that it comes from a valid account. This is how the target application knows which account to act on.

Some APIs send notifications when particular events happen, which an integration can react to as they arrive. These are called webhooks. Like notifications on your phone, they include data about what’s happen and give you an opportunity to respond.

Some APIs, called polling APIs, don’t offer webhooks. Instead, the integration sends integration instead polls the application, sending requests for updates at regular intervals. While these affect how an integration is designed, there’s almost no difference in the end product.

An integration is modular when the movement of data between the integrated applications is decoupled from the the workflows and logic that process that data.

Every application uses and stores data in a slightly different format. A traditional software integration works by taking data from one application’s API and transforming it into the format for the other application, performing any transformations or additional task to the data as part of the transformation.

This traditional approach means building an integration can take a long time and cost a lot, as the developers have to scope out what the integration has to do in minute detail and then code each functionality piece by piece.

Rather than writing code that only works for integrating one specific pair of applications, our modular integrations are constructed of pre-built code blocks or modules which we connect together during implementation. One code block handles communication with either application being integrated, while the movement and transformation of that data is handled by entirely separate blocks of code inside Ferrio Connect.

All this means when we set out to integrate two pieces of software for a customer, 90% of the work is already done — we’re just configuring the integration around the last 10% that’s unique to your business, such as which references you use to map sites and jobs, or how to handle any custom fields that are used on either application.