What is an API, in two lines: it is the set of rules and channels through which one piece of software lets another ask it for data or tell it to do something, automatically and without a person acting as go-between. APIs are what let your online shop tell the ERP about a new order, or let the CRM receive a customer's details as soon as the accounts team creates them.
API stands for Application Programming Interface. The name sounds intimidating; the idea is much less so. Below you will find an explanation without jargon, examples taken from real SMEs, what you actually need to connect two programs, which risks to keep an eye on and how complicated it is to do.
APIs explained without jargon
The word that matters is interface, the point where two things meet. Your screen and mouse are the interface between you and the computer. An API does the same job, but for programs: it is a set of "questions" a piece of software accepts and "answers" it gives back, always in the same format.
Whoever uses an API does not need to know how the other software works inside. The rules are enough: what you can ask for, how to ask for it, and what will come back.
The waiter metaphor
The most common image is the restaurant. You are the customer; the kitchen is the system that prepares the dishes, for example the ERP. You do not walk into the kitchen. You call the waiter, choose from the menu, he takes the order to the chef and comes back with the dish.
The API is the waiter and the menu is the list of things you can ask for. If you order a dish that is not on it, he says no. If you order correctly, you get exactly what you asked for, and you know nothing about how the kitchen works, nor do you need to.
Another image: the power socket
To plug in a toaster you do not call an electrician. You push it into the socket, because socket and plug follow a standard. APIs work in a similar way: if a piece of software exposes a documented API, another program can plug into it by following that standard, without taking anything apart.
What APIs do in an SME
If someone in your company spends hours copying data from one program to another, the first thing APIs do is eliminate that work. An order is entered once and reaches the warehouse, invoicing and shipping without anyone retyping it.
The second use is keeping data aligned. You change a customer's address in the CRM and it changes in the ERP too, which ends the argument about which of the two files is the right one.
Then there are external services. Online payments, courier tracking, maps, e-invoicing: many providers offer ready-made APIs, and your software can use them instead of reinventing them.
The last use is opening up your data to customers and sales reps, within limits. An app for your sales network or a customer portal that shows order status reads data from the ERP through APIs, and shows only what you decide.
The common thread is simple: different programs work together, and people stop acting as the bridge between one program and the next.
Two real examples
Metaphors only go so far. These are two cases we come across often in the companies we work with.
The online shop that talks to the ERP
A spare parts distributor sells online and in its shop. Without a connection, every web order is printed or read on screen and re-entered by hand in the ERP. Meanwhile the stock shown on the website is yesterday's, and sometimes a part gets sold that is no longer in the warehouse.
With an API connection, when the customer confirms the purchase, the online shop sends the order to the ERP. The ERP deducts the stock and sends the updated availability back to the website. When the parcel leaves, the tracking number goes back to the website and the customer gets the email. Nobody has copied anything. The full flow, step by step, is in our guide to integrating your online shop with your ERP.
HubSpot CRM synced with business software: the Pulltex case
Pulltex, a wine accessories brand that sells to wineries, consortia and distributors through a network of sales reps, used HubSpot to manage deals. Pro forma invoices, however, were produced on a separate system or in spreadsheets, and keeping track of which rep handled which customer was hard.
For them we built custom web-based business software connected to HubSpot through a two-way API integration. The software syncs customer data with the CRM, imports deal owners from HubSpot and sends the generated pro forma invoices back to HubSpot, so the history of every deal also contains the sales documents. HubSpot stayed where it was, alongside a tool that speaks its language. According to the results reported in the Pulltex case study, the time needed to create and send a pro forma invoice fell by 70%.
How an API call works, step by step
You do not need to know how to code. Understanding the mechanism, though, helps a lot when you talk to vendors and developers.
- Program A sends a request to a specific address of program B, which in the jargon is called an endpoint. For example "give me the list of today's orders" or "create this new customer".
- Along with the request, A presents its credentials, usually an API key or a token. It works like a badge at the entrance: without it, B does not respond.
- B checks that A has permission to do that and that the request is written correctly.
- B carries it out and replies with structured text, often in a format called JSON, which A knows how to read. If something goes wrong, the response contains an error code explaining why.
The whole round trip takes a fraction of a second and can happen thousands of times a day without anyone noticing.
The types of API you will hear about
When you ask for a quote to connect two programs, sooner or later someone will say "REST", "webhook" or "SOAP". These terms are less complicated than they sound.
REST APIs
This is the most widespread type today, and it works like the web: every object (a customer, an order, a product) has its own address, and a few standard actions are used to read, create, update or delete it. Almost all the cloud software you use, from CRMs to online shops, offers REST APIs.
Webhooks
With a classic API, it is your program that goes and asks whether there are new orders. If it checks every five minutes, sometimes it finds something and often it does not. A webhook reverses the logic: the other software tells you the moment something happens. It is the difference between calling the pizzeria every ten minutes and waiting for the delivery driver to ring the bell. For events such as "new order" or "payment received", a webhook is almost always the more efficient choice.
SOAP and GraphQL, briefly
SOAP is an older, more rigid standard that you still find in many legacy business systems, in banking and in some public administration services. It works, but integrating it takes more effort. GraphQL is more recent: with a single request you ask for exactly the data you need, instead of piecing it together from several calls. Several modern platforms use it.
| Type | How it works, in short | Where you usually meet it |
|---|---|---|
| REST | You ask, using standard actions on specific addresses | CRMs, online shops, cloud software |
| Webhook | The other system notifies you when something happens | Orders, payments, completed forms |
| SOAP | Highly structured messages and strict rules | Legacy business systems, banks, public bodies |
| GraphQL | One request to get only the data you need | Modern platforms |
You do not choose the type: it depends on what the software you want to connect offers. It is enough to know that there are different routes, with different costs and timelines.
What you need to connect two programs via API
This is the question that really counts. These are the things to check, in the order we usually check them.
- That the programs have APIs. Look on the vendor's website for an "API", "Developers" or "Integrations" section: public documentation is a good sign. Watch the price lists, because some vendors include API access only in their more expensive plans.
- Access credentials: API keys or authorised access (often through a system called OAuth) for each program, with the right permissions.
- A data map, meaning which field in one system corresponds to which field in the other. It sounds trivial until you find that one program keeps first and last name in a single field and the other in two, or that the customer codes do not match.
- The rules: which system wins if the data differs, which direction the data travels in, how often, and what happens if one of the two is unreachable.
- Someone to build and maintain the connection. For simple flows, tools such as Zapier or Make are enough. With high volumes, special logic or sensitive data, you need dedicated development.
- A test environment. The connection is tested on copies of the data, so a mistake does not end up on an invoice.
How these pieces come together in a real project, with phases, choices and mistakes to avoid, is covered in our guide to API integration between business systems.
API security and limits
An API opens a door into your software. That is useful, but it has to be managed like any other door.
Treat API keys like house keys: whoever has them gets in. They are not sent by email, not written in a shared spreadsheet and not left with a former contractor. If a key ends up in the wrong hands, you revoke it and generate a new one. The principle of least privilege also applies: a connection that only needs to read orders should not be able to delete customers, and many programs let you create keys with limited permissions. Data must also travel over encrypted HTTPS connections, as when you log in to online banking.
There are technical limits to know about as well. Almost all providers set a maximum number of requests within a given time window, and a badly designed connection can exceed it and stop working on exactly the busiest days. APIs also change: vendors update them and now and then retire old versions, so an integration needs someone who notices and adapts it. Finally, you depend on the other service. If the external software is down, the connection stops with it, and a good design plans what to do in those cases, for example putting requests back in a queue and retrying them later.
If personal data about customers or employees passes through, connections also fall under GDPR obligations: who accesses what, where the data ends up, how long it is kept. For a broader picture, see our practical guide to cybersecurity for SMEs.
How hard is it to use APIs?
It depends on which programs you want to connect, how much data has to pass between them and how reliable the result has to be. Simplifying, there are three cases.
The easy case: two widely used cloud programs, with documented APIs and perhaps a ready-made connector. The contact form on your website creating a contact in the CRM, for instance. It is often solved quickly with a no-code tool.
The intermediate case: software with good APIs but company-specific rules, such as customer-specific price lists, sales reps with different territories, documents that have to flow back. Here you need a custom integration, designed and tested. Pulltex falls into this category.
The difficult case is the old ERP with no API. Even there, there is a way: sometimes you read and write directly to its database with a dedicated connector; other times it makes sense to build the missing APIs. And sometimes the honest answer is that the time has come to change tools.
On our page dedicated to integrations and APIs we give rough timelines for the most common cases. A serious estimate, though, only comes after analysing the programs involved, because that is where the details that shift time and cost turn up: a field that does not exist, a request limit that is too low.
Frequently asked questions about APIs
Is an API a program you install?
No. It is a feature of software you already use, a kind of entrance reserved for programs. You do not install it: you enable it, configure it with credentials and use it.
What is an API key?
It is a long, unique code that identifies who is making a request. The software checks it on every call to decide whether to respond and what to allow. Guard it like a password.
Do you always need a developer?
For simple connections between widely used programs, no: with Zapier or Make you can manage on your own. If there is a lot of data, the rules are complex or the connection supports an important part of the business, it is better to hand it to people who build integrations for a living.
Are API and integration the same thing?
No. The API is the door a piece of software makes available. The integration is the project that uses those doors to move the right data, at the right time, between two or more systems.
Let's talk
If your company has software that does not talk to other software and people acting as go-betweens, there is a good chance APIs can take most of that work off their hands. At Selli we start by analysing your data flows and the programs you use, develop in two-week sprints and test everything in a test environment before touching real data. The code remains yours. Book a call with us: we will look at which connections would save you the most time and how complicated they would be to build.