An API integration is a connection that lets two software systems exchange data and trigger actions in each other automatically, without a person retyping anything. One system sends a structured request, the other answers. It is how a website takes a payment, an app sends a text message, or email attachments file themselves.
Nearly every product we build is partly made of other companies' software. Our attorney marketplace does not move money itself, send its own text messages, or deliver its own email. It asks services built for those jobs to do them, and it asks through their APIs.
Business owners usually meet the term when something does not connect: the booking tool that will not talk to the calendar, the form that does not reach the customer list. So here is what an integration is, what a good one looks like, and what to ask before you buy software that claims to have one.
What is an API integration?
An API integration is two systems talking to each other without a person retyping. An API, or application programming interface, is the set of requests a piece of software accepts from other programs. An integration is the code that uses that API to make two systems work together.
Think of the API as a counter with a posted menu. You may order what is on the menu, in the format the menu specifies. You cannot walk into the kitchen. That restriction is what makes it dependable: the vendor promises the menu will keep working even when they rebuild the kitchen.
A request is small and structured. Here is the shape of one that asks a messaging service to send a text:
await fetch('https://api.example.com/messages', {
method: 'POST',
headers: { Authorization: `Bearer ${process.env.API_KEY}` },
body: JSON.stringify({ to: '+15555550100', text: 'Your hearing was accepted.' }),
});An address, a key that proves who is asking, and the data. Most integrations are variations on that.
What are examples of API integrations?
Common examples of API integrations are taking card payments through a payment provider, sending text messages and email through delivery services, reading a mailbox, saving files to cloud storage, and publishing to a website or social network. In each case one system asks another to do a job it specializes in.
These are integrations in our own projects:
| Project | Connects to | So that |
|---|---|---|
| CoverageCobra | Stripe Connect | Attorneys get paid without anyone chasing an invoice |
| CoverageCobra | Twilio, Resend, Web Push | Alerts go out by text, email, and push notification |
| Firm Mail Intake | Gmail API, Google Drive API | Email attachments land in the correct client folder |
| Social Command Center | Meta Graph API | Scheduled posts publish for several companies |
| Content Engine | WordPress REST API | Finished articles publish without anyone opening the editor |
None of these services are ours, and we would not want them to be. Building a payment system or a text message network is a company's whole job. Using theirs through an API is the sensible choice, as we discuss in build vs buy software.
How does an API integration work?
An API integration works by sending authenticated requests between systems and handling the answers. Your software sends a request with a key, the other system does the work and replies. For events that start on the other side, that system calls your software instead, which is known as a webhook.
The moving parts:
- Credentials. A key or token that identifies your software. It is a password and must be stored like one. See environment variables and secrets.
- Requests. Your code asks for data or an action.
- Webhooks. The other system notifies you when something happens, such as a payment completing.
- Error handling. The other service will sometimes be slow or down. Your code decides whether to retry, queue, or alert.
- Limits. Most APIs cap how many requests you may send in a period. Good integrations stay under the cap.
Item 4 is where most of the real work is. Sending a request that succeeds is easy. Deciding what happens when a payment notification arrives twice, or not at all, is the part that separates an integration that works in a demo from one that works on a Monday.
What is the difference between a native integration and a custom one?
A native integration is a connection the vendor built and maintains, usually switched on in settings. A custom integration is code written for your business against the vendor's API. Native is cheaper and faster when it does exactly what you need. Custom is for when it does not.
Use the native option first. If the two products you own already connect and the connection does what you need, there is nothing to build. Custom work earns its cost when you need logic the native version lacks: matching records by your own rules, combining three systems, or handling volume. We compare the middle ground in no-code automation vs custom code.
Every outside service is also a dependency. Our CaseCobra motion engine replaced a separate app that leaned on five outside services. The rebuilt version leans on none. Integrate where a service does something you cannot reasonably do yourself, and not out of habit.
What should you ask a vendor about their API before you buy?
Before buying software, ask whether it has a documented public API, whether that API can both read and write the data you care about, whether it is included in your plan, and how you get your data out. A product with no usable API will eventually trap your information.
The questions we ask:
- Is there a public API, and where is the documentation? If the answer is "contact sales", be cautious.
- Can it write as well as read? Many APIs expose reports but will not accept new records.
- Which plan includes API access? It is often reserved for higher tiers.
- Does it send webhooks? Without them, you have to keep asking whether anything changed.
- What are the rate limits?
- Can I export all of my data, in a standard format, without asking anyone?
- How are changes announced? A vendor that versions its API and gives notice is one you can build on.
Ask these before signing, not after. The answers cost nothing and they tell you how hard it will be to connect this product to everything else you own, or to leave it.
Frequently asked questions
Do I need a developer to set up an API integration?
Not always. Native integrations and no-code connectors cover many simple cases. You need a developer when the connection involves your own business rules, more than two systems, or data where a mistake is expensive.
Is an API integration secure?
It is as secure as the handling of its credentials and the access they carry. Use keys limited to what the integration needs, store them outside the code, and replace them when someone with access leaves. Connections should always use HTTPS.
What happens when the other company changes its API?
Well-run APIs are versioned, so existing integrations keep working for a published period. Someone still has to make the update before the old version is retired. This is ordinary maintenance and should be planned for.
What is the difference between an API and a webhook?
With an API, your software asks. With a webhook, the other system tells you when something happens. Most real integrations use both.
If two of your systems should be talking and are not, tell us which ones. We will check whether a native connection exists before suggesting anything custom.