What Are APIs and Integrations? An Explanation for the Non-Technical

Many founders understand that product integrations can drive revenue, but they aren’t clear on the technology to make it happen.

In the SaaS world, product integrations have become vital for success. The average fast-growing SaaS company has a median number of 15 product integrations.

But what exactly is an API and what exactly is a product integration?

Many founders, partnerships, and sales leaders understand product integrations can drive revenue, but they aren’t clear on the technology they need to make that happen. Here are explanations of the basic terms.

What is an API?

APIs are not product integrations, but the interface most commonly used to build product integrations.

Having a well-designed API is key to attracting other companies to build integrations into your application, and to giving your customers the ability to accomplish their business objectives.

The API is an interface that abstracts away from the custom code of each application, helping the two applications to communicate without knowing the details of the other application.

Metaphorically, you can think of it as a person who speaks French (SaaS application 1) who is trying to do business with someone who speaks Spanish (SaaS application 2). While neither person understands the other language, they both know some English (the API).

In order to communicate and make requests and responses to each other, they have to use the English words they both know. It is a standardization that empowers them to exchange information.

It is key that they know the relevant English words — for example, if a person is in a store, “How much does that cost?” and “It costs X dollars” would be important, while knowing, “What is your favorite movie?” would be much less essential.

Similarly, the design of the API will specify how the applications can interact with one another. You pick the verbs (like get or delete) and the nouns (like names or emails) that other applications must use to talk to your application.

Think of it as your product has custom and complex code, and so do all the other products. An API is a more abstract layer that means products can talk to each other without needing to see or access the other product’s custom code.

This makes communicating easier as you don’t have to learn the other system; you can just learn the API, which is more standardized. It is also more secure since you don’t need to be inside the other application’s database to exchange data.

What are the common styles of APIs?

The most common style of APIs for modern SaaS companies is REST API with a JSON response.

SOAP is an older protocol that is still used. SOAP’s advantages are greater standardization and built-in security, while REST’s advantages are speed, scalability, and flexibility. Practically, SOAP is most commonly used in legacy applications, in enterprises, or when partners need a rigid protocol to enforce.

GraphQL is a style that is currently growing more popular. It can be more efficient than REST, and hence faster. It can also be better for making more modifications over time as REST might have more breaking changes that require customers and partners migrate to a new version of the API.

So what is a product integration?

An API is the most commonly used tool to build a SaaS integration—an application that connects two systems and enables data to move between them.

A product integration is a type of integration that enables all customers of a SaaS company (on the relevant plan) to move the data from that account to their account with a different SaaS application.

So, for example, if Busy Bee’s Soap wants to move their list of Zoom webinar attendees into Hubspot, they could download the CSV file of the attendees from Zoom, re-format it, and then upload the list into their Hubspot account.

This is not an integration because Hubspot and Zoom are not talking to one another. And, of course, it takes a significant amount of time to manually move data like this, and it opens the door for human errors.

Instead, Busy Bee’s Soap’s developers might build an integration for themselves using Hubspot’s and Zoom’s APIs. The Busy Bee’s developers could program their integration so the attendees’ name and emails are automatically sent to Hubspot, where they become a new contact or are noted in an existing contact as being a webinar attendee.

That would be an integration built by Busy Bee’s, and the advantage is, within the constraints of the Hubspot’s and Zoom’s APIs, Busy Bee’s can customize this integration to their particular business needs.

In contrast, a product integration would be if Hubspot builds an integration to Zoom (or vice versa) so their joint customers can access the functionality outlined in the paragraph above.

In this case, Busy Bee’s Soap — as well as every other Hubspot and Zoom customer on the appropriate plan — doesn’t have to build anything; they can simply follow the instructions from inside Hubspot or Zoom to install and run the product integration.

The plus side of this is Busy Bee’s developers do not have to be involved. The potential downside is that the Busy Bee’s marketer is dependent on whatever options Hubspot designed for the integration. If Hubspot required, for example, that someone who registers on Zoom enters their name, email, and company to be added as a contact in Hubspot, that might not align with the marketers’ goal to require fewer fields.

Product integrations can be relatively simple — say sending the emails and names of people who registered for the Zoom webinar into a contact field in Hubspot — or rather deep and complicated — sending data back and forth between systems where the underlying fields are not the same.

Other things being equal, the more complicated the integrations are, the longer they take to build.

As a business, it is imperative the configurations of the integration empower the user of the application to accomplish their goals.

Understanding all the tech terms that go into product integrations can facilitate internal conversations with your product and engineering team.

These conversations can help ensure that integrations meet business objectives, and give both partners and customers a better user experience.