If you’re trying to connect two apps together to share data between them, you’ll probably use both APIs and integrations. But how do these work, and how do they differ? We’ll answer these questions and more below.
In summary, APIs are standardized procedures for sharing data between apps. Integrations are programs that allow apps to connect and share data regularly.
These are related and often work together. Many integrations use APIs to share data, though not all. And APIs can be used by themselves, though they’re most often used with integrations.
Next, we’ll dive deeper into these two concepts so you can visualize how they work together.
API stands for application programming interface. It’s a set of rules that define how an application or server shares data with other apps. The rules include how to send a request to the server where the data is stored and what kind of data can be accessed.
An application can share its API with other developers so they can access its data and use it for their own purposes. Without an API, the application would have to share its entire database with third parties, which would pose a huge security risk.
You can think of an API like a menu at a restaurant. The restaurant decides what it serves and how to order each item. You can’t barge into the kitchen, look through all the ingredients, and whip something up for yourself. Instead, you talk to the waiter, ask for a menu item, and wait for them to bring it out to you.
In the same way, an API presents a “menu” of data that you can access from a third-party app or server. Getting this data requires a specific request in a specific coding language, following a specific format. (This is written out inside the API’s instructions.) If you send the specially formatted request to the right server, you’ll get the data you want.
Just like the restaurant example, you’re not allowed to go into the app’s private database and poke around. Instead, you’re limited to the data points made available through the API.
Without an API, developers would have to go through every application or database they want to connect with and code a custom solution every time.
Not only would that take dozens of hours for every single new connection, but it would also expose a company’s private database and code to external parties.
APIs solve these issues and bring the following benefits:
Again, it’s not a matter of using an API or not. APIs are a must if you want to access data from another app or share data from your app with others.
In an interview on the Between Product and Partnerships Podcast, Stoplight CEO Steve Rodda said, “If software’s eating the world, APIs are the teeth. Whether you think you’re an API company these days or not, you are. Your developers are using them constantly.”
Simply speaking, an API has two parts: a program running on a server and a set of rules for accessing it.
For example, the Weather Channel has an API for accessing weather data, which Apple uses for its Weather app.
Apple might send a request for the “hourly weather forecast in Boston.” The Weather Channel API includes a program that will read the request and send the hourly stats for Boston, and Apple Weather will display it inside the app.
The second piece is a set of documentation that shows developers exactly how to send requests. Things like what programming language they need to use, how to format the code, and where to send the request. When developers follow these instructions, they’re able to get a response from the server with the data they need.
APIs can be structured in many different ways. (By the way, this technology existed before the internet, so internet-based APIs are also called web APIs.)
Today, 3 main types of API architecture dominate the landscape: REST, GraphQL, and SOAP.
In our survey of 400 SaaS businesses, we found that most companies offer REST APIs. This is because developers are comfortable with this format and find it easy to use. SOAP is an older format that still exists in some places, while GraphQL is a newer method that’s beginning to spread.
Besides the architecture type, you can also define APIs by their availability. Open APIs are usually open-source and use public data, while public APIs are listed publicly but may use public or private data. Private APIs are shared only with approved partners or vendors. And internal APIs are exclusively for sharing data within an organization.
Google offers a Places API that allows other apps to download and use location data from Google Maps.
LinkedIn offers a set of Reporting APIs that can send LinkedIn Ads data and analytics to another app.
Shopify’s Admin API allows other apps to edit and add products, access sales data, and more.
Because APIs are so crucial in helping apps and databases share data with each other, this is one of the most common ways to connect apps together.
However, an API itself doesn’t allow a constant sharing of data on a regular basis. For that, you’ll need a program that can consistently send requests to the API and receive the latest data on autopilot.
This program that sends regular requests is called an integration, which we’ll look at in detail below.
An integration is a program designed to connect two different apps together so they can send and receive data regularly.
For example, you could connect a payment processor like Stripe to a CRM like Salesforce. That way, you could keep track of new customer data, purchases made, and other sales data inside the CRM. Instead of having to send requests to the API manually, the data is always synced.
Integrations usually work by connecting two apps through an API, though they may use other methods.
API-based integrations work by sending requests to an API at a set interval, like once a day or once a minute. For example, you might have an integration that requests your latest sales data from the Stripe API each minute and loads it into your CRM dashboard.
Another way that integrations can work is by using webhooks. Webhooks work in the opposite way of APIs. They send a trigger every time new data is added.
For example, instead of sending a regular request to an API every minute, you might have a webhook that sends a ping every time a new sale comes through Stripe. The ping sets off the integration, which requests the data from the Stripe API and sends it to Salesforce.
Integrations can be made in many ways, but here are two of the most common types:
Another way of understanding integrations is how they’re used within a business.
Some integrations are internal only. For example, accounting data might be shared with a CRM or reporting software for internal reporting.
Other integrations are user-facing. Your app's users can choose to connect their accounts with other apps to share data. For example, ecommerce fulfillment solution ShipBob offers its users the ability to connect to Shopify, TikTok Shop, and other ecommerce apps.
With integrations, data is automatically shared between applications, and it’s always up-to-date. Instead of having to resend a request to an API every time you want the latest data, the integration does all the work for you.
On the business side of things, offering user-facing integrations is an important part of ecosystem-led growth. User-facing integrations can help your business grow by:
Justuno, a Pandium customer, is an AI-powered lead gen and conversion optimization platform for e-commerce. It offers user-facing integrations with leading e-commerce apps like Shopify and BigCommerce and martech like Constant Contact and Facebook Messenger.
Salesforce offers user-facing integrations with marketing apps like Meta Ads and thousands of others. ZoomInfo offers an integration with Salesforce to show CRM data in searches.
Internal integrations might connect functions within your organization, like automatically sending lead data to your sales team or allowing HR to access a database of employee data.
An integration is simply a formal way to connect two apps or databases. It’s the primary way your organization will sync and share data with both internal and external sources.
The question is, how will you build those integrations?
Traditionally, businesses have relied on two ways of creating integrations. Either a team of developers will create a brand-new integration from scratch, or they’ll use a low-code integration platform to set up connections in a few clicks.
Low-code integration platforms make it easy for anyone in the organization to connect apps and data in a few clicks. The platform has pre-coded connectors that can be set up using a drag-and-drop interface and entering an API key. These platforms work well for internal integrations that are for your eyes only.
But if you plan to offer native integrations to your user base, low-code integration platforms can introduce problems.
First, the existing code used to connect apps can bloat your app’s codebase or slow down your app for users. And since integration platforms like these only offer a pre-defined set of customization options, you may not be able to meet the needs of every user. Finally, there’s no predicting how these low-code integrations will perform when they’re deployed to thousands of users at the same time.
That’s why coding integrations from scratch is still the preferred way to make external, user-facing integrations.
But there’s still an issue. Developing an integration from scratch can take months and distract developers from their work on core features. Each integration can cost hundreds of thousands of dollars, which not every SaaS can afford.
That’s why at Pandium, we’ve built a code-first platform that gives you the tools you need to code custom integrations for any app, in any programming language, in a fraction of the time and budget.
Justuno was able to code a new integration every week using our platform, while ShipBob drastically cut engineering time for integrations and increased their partnerships by 450%.
Set up a demo to explore how Pandium can help you create industry-leading integrations for your B2B SaaS in a fraction of the time and budget.
