What Is an API and Why Does Your System Need One?

An API is an agreed-upon entry point into a piece of software that lets other programs fetch and send data automatically, with no person copying things across. If you're asking what an API is because someone told you your systems "need to talk to each other", this is the answer: it's how an order in your online store becomes an invoice in your accounting software and a contact in your CRM without anyone retyping it.

A system with an API can plug into the rest of your business. A system without one becomes an island where data moves by hand. Below I explain how it works without a single line of code, using the kind of tools most European small and mid-sized businesses already run.

The short answer: what an API does for your business

The quickest way to understand APIs is to compare the same workday with and without them, here for a company selling through an online store.

My rule of thumb: if the same piece of information gets typed into two systems several times a week, look into whether an API can take over. To see where integrations fit into a full build, read my guide to the software development process from idea to launch.

What is an API? A plain-English explanation

API stands for Application Programming Interface. The name is intimidating, but the idea is familiar if you've ever ordered from a wholesaler. You don't walk into their warehouse and pick items off the shelves. You hand over an order form in a fixed format and get a confirmation back in a fixed format. Fill the form in wrong and it comes back with a reason.

An API works the same way, just between two programs. There are five parts:

• The request: one system asks for something, like "give me all unpaid invoices" or "create this customer".
• The response: the other system answers in a fixed format, usually JSON (structured text machines can read easily), along with a status code saying whether it worked.
• The endpoint: each type of data has its own address. One for customers, one for invoices, and so on.
• The key: access requires a key or login, so the system knows who's asking and what they're allowed to do.
• The documentation: the description of what you can ask for and in what format. An API without good documentation is an order form without instructions.

The part that matters for you is that an API is a contract. The system promises to answer in a certain way as long as you ask in a certain way. That's why two products from different vendors can work together without knowing anything about each other's internals. The API lives in your system's backend, and I've explained how that fits with the other layers in what a tech stack is.

People often mix up two terms here. The API is the power socket, and the integration is the cable and the appliance. The vendor provides the API; the integration is the code someone writes to use it. For a hands-on example with Nordic accounting software, see my guide to building an e-conomic API integration.

An API example: one order through six systems

Picture a Scandinavian company that sells coffee and coffee machines to offices across Europe through an online store. A customer orders a case of beans and a set of mugs. Here's how that order travels when the systems are connected through APIs:

1. The customer clicks "Pay". The store asks the payment provider, say Stripe, to charge the card through the provider's API.
2. The payment provider reports back once the payment succeeds. That's called a webhook: instead of the store asking every minute, the provider sends the message itself.
3. The store creates an invoice in the accounting software (Xero, Fortnox or e-conomic, depending on the country) with the customer, line items and VAT. That only works because the business approved the connection beforehand. In e-conomic, for example, the business approves the app, which then receives a token for that one company's books.
4. The warehouse system is told to reserve the items, and the store pulls the updated stock level so the next customer can't buy something that's sold out.
5. The carrier's API creates a shipping label and a tracking number, which is emailed to the customer automatically.
6. The CRM receives the customer and the order, so the sales rep can see the history before the next call.

Six systems, zero manual entry. Without APIs, each step is a person copying details between screens. That's manageable at a handful of orders a day. At scale it becomes a time sink and a steady source of mistakes.

Notice that the systems don't all talk to each other directly. The store runs the show and calls the others, and deciding which system plays that role is one of the first choices in any integration project.

Why does your system need an API?

When people ask whether their system needs an API, they usually mean one of two things, and each has its own answer.

Your system needs to use other systems' APIs

This is the most common need. Nearly every business system has to talk to accounting, payments, email and often a CRM. If you're building a web app or a customer portal, it should be designed from day one to send and receive data from the tools you already use. Otherwise your team ends up moving data by hand, and the system loses much of its value.

Your system can offer its own API

The next step is for your own system to expose an API to others. That makes sense when:

• You'll want a mobile app later. A mobile app talks to the same backend as your web app, and it does so through an API.
• Customers or partners want to connect. A B2B customer might want to send orders straight from their own purchasing system instead of using your store.
• You want to be able to switch tools without starting over. If your data can be pulled out through an API, you're in a stronger position, and it's one of the best ways to avoid vendor lock-in.
• You want to automate with tools like Zapier, Make or AI assistants. They all need a way in.

But only build it once someone will actually use it. An API nobody calls is just more code to maintain and secure. My recommendation is to build your system so an API is easy to add, then wait until someone needs it.

What to sort out before you connect your systems

Making the API call is rarely the hard part. The hours and the risk sit in everything around it. These are the five things I always clarify before I quote on an integration.

Access and keys

An API key is a password for a program. It belongs on a server, not in an email thread or a shared spreadsheet. Many providers also separate test keys from live keys. Stripe, for example, issues separate keys for its sandbox and for live payments and recommends restricted keys that carry only the permissions an integration actually uses. Make sure accounts and keys are registered to the company, not to a former employee or contractor.

Rate limits

Most APIs cap how many requests you can send. At HubSpot, the limit for private apps on the Free and Starter plans is 100 requests per 10 seconds and 250,000 per day. That's plenty for daily use, but a first import of tens of thousands of contacts needs to be paced so it doesn't get rejected halfway through.

Changes and versions

APIs change. Vendors retire old versions, and integrations have to follow. Budget for ongoing maintenance and agree on who keeps an eye on the vendors' change notices.

Failures and monitoring

What happens when the other system is down for an hour? A good integration retries, logs the error and alerts a person. The most expensive failure is the silent one that runs for three weeks before someone notices the invoices never reached the accounting software.

Personal data and security

If the integration sends personal data to a vendor that processes it on your behalf, that vendor is usually a data processor under GDPR, and you need a data processing agreement. The EDPB's guide for small businesses explains the controller and processor roles and the contract that Article 28 of the GDPR requires. Check with a legal advisor if your situation is unclear. And if your system gets its own API, it needs the same protection as the rest of the app; the usual weak spots are covered in my web application security checklist.

How to check whether a system has a usable API

You don't need to be a developer to do a first assessment. If you're choosing a new tool, or want to connect two you already have, work through these steps:

1. Find the documentation. Search for the product name plus "API" or "developers". Public, current documentation is a good sign. Having to go through a sales rep to see it is a bad one.
2. Check what you can read and write. Plenty of APIs let you read invoices but not create them, or handle customers but not the custom fields you've added.
3. Check whether API access comes with your plan. Some vendors only include it on higher tiers or charge extra.
4. Check whether the system can push notifications through webhooks. If not, the integration has to keep asking at fixed intervals, which means delays and more requests.
5. Check for a test environment. e-conomic offers a free trial account with demo data, and Stripe has a separate sandbox, so the integration can be tested without touching real data.
6. Check the limits. How many requests are allowed, and how much data can you fetch at once?
7. Write down which data moves, when, and which system wins when two disagree. That belongs in your software requirements specification.

If you can tick the first five, you have a solid foundation. If several come back as a no, talk to a developer before you commit to that tool.

When you don't need an API

I build integrations myself, so read this section with that in mind. Still, there are plenty of cases where building something custom doesn't pay off:

• Your volumes are low. If you send ten invoices a month, typing them takes less time than building, testing and maintaining an integration.
• A ready-made connector exists. Most major tools have an app marketplace or a list of native integrations. A subscription is almost always cheaper than custom development plus upkeep.
• An automation tool can handle it. Zapier and Make use the APIs for you and work well for simple flows like "new form entry, new contact". Once the logic gets complicated or errors need proper handling, they hit their limits fast.
• A file is enough. If your accountant needs a monthly report, a spreadsheet export is often fine.
• The system has no API at all. Then the real question is usually whether to switch tools, not whether someone should build a fragile workaround.

Next steps

If you need an integration built, prepare the following before your first call with a developer. It saves meetings and gets you a more accurate estimate.

If you want to see how I build web apps, portals and internal tools that connect to your accounting, CRM and payment systems, take a look at my web app and platform development service.

Frequently asked questions

What is a REST API?+

A REST API is the most common way to build APIs on the web. Each type of data has its own address, and standard web commands are used to read, create, update and delete it. Responses usually come back as JSON. You'll also run into GraphQL, and older SOAP APIs in some ERP and public sector systems. As a buyer, the style matters less than whether the API is well documented and stable.

Do APIs cost money to use?+

Often not directly, but there's almost always a cost somewhere. Some vendors only include API access on certain plans, and others charge per request or per transaction, as with SMS, payments or AI services. On top of that comes building and maintaining the integration itself. Ask both the vendor and your developer about running costs before you commit.

Can you integrate systems without an API?+

Yes, but it's fragile. The alternatives are swapping files, such as a CSV export picked up every night, or having software click through screens the way a person would. The second approach breaks every time the vendor changes its interface. Use it as a stopgap only, and consider whether a tool with a proper API is the better long-term choice.

Is an API a security risk?+

An API is a door into your system, so it's only safe if that door is properly locked. That means authentication with keys or logins, permissions that control who sees what, encrypted connections, rate limits and logging. The most common mistakes are APIs that return more data than needed, or that don't check whether the user is allowed to see that specific record.