Most business software does not work in isolation. An e-commerce platform needs to communicate with an inventory system. A CRM needs to push data to a marketing automation tool. An accounting system needs to receive data from a payment processor. The mechanism that makes this communication possible is an application programming interface, almost universally referred to as an API.
APIs have moved from a technical concept relevant only to developers into a business consideration that owners and managers encounter regularly: when evaluating software, when planning technology projects, and when trying to understand why data in one system does not match data in another. This guide explains what APIs are, how they work in practice, and what business leaders need to understand about integration to make better technology decisions.
At mackenna-and-janssen.net you will find a magazine covering computing, apps, and cloud services, with practical guides for businesses and technology professionals.
Table of Contents
What an API Is and Why It Matters
An application programming interface is a set of rules and specifications that allow different software systems to communicate with each other. It defines the ways in which one application can request data or actions from another, and what the response will look like.
The practical implication for business is that APIs are the infrastructure of software integration. When your CRM automatically creates a customer record when an order is placed in your e-commerce platform, an API is making that communication happen. When your accounting software pulls in bank transactions automatically, an API is the mechanism. When your HR system sends a new employee record to your payroll system, that is an API call.
The quality, availability, and documentation of a software product’s API is therefore a factor in evaluating that product, particularly for businesses that expect their software tools to work together. A product with a well-documented, stable, and capable API is easier to integrate with other systems than one whose API is limited, undocumented, or unreliable.
Types of Integration
Integration between business systems can be achieved in several ways, ranging from direct API connections built by developers to no-code integration platforms used without programming knowledge.
Direct API integration involves a developer writing code that connects two systems by making API calls. This approach is the most flexible and can be tailored precisely to the requirements, but it requires technical expertise to build and maintain. When the APIs of the connected systems change (which vendors do periodically), the integration code needs to be updated.
Integration platforms (Zapier, Make, n8n, and in more complex enterprise contexts, Workato or MuleSoft) are middleware services that connect to the APIs of many different software products and allow you to create automated workflows between them without writing code. A non-technical user can configure an integration that automatically creates a task in a project management tool when a deal reaches a certain stage in the CRM, for example. These platforms reduce the technical barrier to integration significantly but have limitations in the complexity of logic they can handle and the volume of data they can process cost-effectively.
Native integrations are built-in connections between two specific products, typically built by one of the vendors specifically because enough customers use both products to justify the development investment. They are the easiest to set up (usually a few clicks to authenticate and configure) but are limited to the specific integration the vendor has built, with no customization.
Planning an Integration Project
Integration projects are consistently underestimated in complexity and overestimated in speed of delivery. A clear understanding of what the integration needs to accomplish, what data needs to flow between which systems, and what the acceptable states for that data are reduces the risk of a project that takes much longer and costs much more than anticipated.
The starting point is a data mapping exercise: what data needs to move from which source system to which destination system, how that data is structured in the source, how it needs to be structured in the destination, and what transformation (if any) is required in between. A customer record in one system may use different field names, different data formats, and different categories than the destination system expects. Identifying these differences before development begins allows the integration to be built correctly from the start.
Error handling is a component that is frequently underspecified. What happens when an API call fails? What happens when data from the source system is incomplete or in an unexpected format? What happens when the destination system rejects a record? Integrations that do not handle errors gracefully either fail silently (data does not move without anyone noticing) or fail noisily (errors that someone needs to investigate and resolve manually). Neither is acceptable in an integration that business processes depend on.
Testing integration should use realistic data, including edge cases (records with missing fields, unusual characters, data at the extremes of expected ranges) rather than only clean, well-formed test data. Production data is always messier than test data, and integrations that work perfectly in testing can fail on real data in ways that are difficult and time-consuming to diagnose.
Evaluating API Quality When Choosing Software
When evaluating software products that will need to integrate with other systems, the quality of the API is worth assessing before purchase rather than after. The questions to ask or research: Does the product have an API? (Not all do.) Is the API documented, and is the documentation clear and current? Are there rate limits that could constrain the volume of API calls your integration would require? Is the API stable or subject to frequent breaking changes? Does the vendor provide a sandbox environment for testing integrations before deploying to production?
A product that does not have an API, or has a limited API that does not expose the data or actions you need, will require workaround solutions (manual data exports, file-based transfers) that are more fragile and more labor-intensive than API-based integration. Discovering this after purchase rather than before is an avoidable problem.
The existence of a marketplace of pre-built integrations (listed in the product’s documentation or app marketplace) is a useful signal. If many other companies have already built integrations between a given product and the tools you use, the API is probably capable of supporting those integrations and there may be pre-built solutions available that reduce the cost of integration.