What is an API? A plain-English explanation for business owners, with real examples

An API (application programming interface) is an entry point that one piece of software opens to other software. It lets them ask it for information or tell it to do something, according to rules written in advance, without a human clicking through a screen. For a business owner, the essential idea fits in one line: an API is what stops people retyping data between two tools.

This guide explains the principle without jargon, using examples you already rely on: electronic invoicing, your bank, your accounting software, online payments. It then answers the questions that matter for a decision: what APIs change for your business software, what drives the cost of an integration, and what to ask before you sign up for a new tool.

The best picture: a service counter with a form

You may have heard the restaurant analogy, where the API is the waiter carrying orders between you and the kitchen. It works, but it misses the rules. A better picture is a public office that only deals with people at a counter. To get anything, you fill in a specific form, show proof of who you are, and the answer always comes back in the same format. You never walk into the back office and never see how your file is handled: you only know what you can ask for and what you will receive.

An API works exactly like that:

• the form is the request: what your software asks for, in a required format;
• the proof of identity is the API key (or token), which shows your software is allowed to ask;
• the standard answer is the data sent back, always in the same structure, which your software knows how to read;
• the rules posted at the counter are the documentation: the list of what you can ask for, and how.

The software that opens its API stays in control. It decides what it exposes, to whom, and within which limits.

A real example you can try yourself

The Global Legal Entity Identifier Foundation (GLEIF) publishes the GLEIF API, which gives access to the public record of every company holding a Legal Entity Identifier (LEI), the 20-character code used worldwide in financial reporting. When we checked on 7 November 2026, a simple search worked with no key and no sign up. The request is just a web address ending with what you are looking for:

https://api.gleif.org/api/v1/lei-records?filter[fulltext]=bakery

The answer is structured text, readable by a program, that lists the same fields for every company found, always in the same place: lei, legalName, legalAddress, jurisdiction, status and so on. Your software therefore knows exactly where to read each piece of information.

In a quoting or onboarding tool, this lets someone type a new customer's name and watch the record fill itself in, legal address included. Many countries run a similar service for their own company register, sometimes with a free key to request first. That, in miniature, is all an API is: a request, an answer, and rules of use.

Four examples you already depend on

Electronic invoicing

Across Europe, business-to-business invoices are moving to structured electronic formats, often exchanged over networks such as Peppol or through platforms approved by the tax authority. France, for example, is making e-invoicing between businesses mandatory through approved platforms. For an invoicing tool or business application to send invoices without anyone downloading and re-uploading them by hand, it connects to one of these platforms through its API. We built exactly that for Izi-Devis, the quoting and invoicing software for tradespeople that LPR Studio publishes and runs itself: the connection to an approved platform is currently in acceptance testing on that platform's test environment. The French timetable and formats are covered in our article on the French e-invoicing mandate.

Your bank

Since the EU's second Payment Services Directive (PSD2, Directive 2015/2366), banks must give regulated providers access to payment accounts: account information services (which read balances and transactions) and payment initiation services (which start a transfer with the account holder's consent). The UK runs its own open banking framework on the same idea. This is how your accounting software picks up your bank feed every morning. For a business application, the normal route is not to connect to each bank directly but to go through one of these regulated providers, which exposes its own API.

Your accounting software

Most cloud accounting tools, Xero and QuickBooks among them, publish developer APIs. Take Pennylane, a French accounting platform, as a documented example. Its developer documentation describes an API covering customer and supplier invoices, customers, ledger entries, bank transactions and their matching to invoices, with webhooks to be told when something changes. Access uses a company token or OAuth 2.0, with scopes that limit rights to what is needed (read-only access to customer invoices, for example). In practice: an invoice approved in your business application can land in the books without retyping, and its "paid" status can flow back the other way.

Online payments

Stripe describes its API as organised around REST, with predictable addresses and JSON responses. One point matters a great deal to a business owner: Stripe provides sandboxes, isolated test environments where payments are not processed by card networks or payment providers. You can try everything, declined cards and refunds included, before the first real payment. Our article on SaaS subscription billing with Stripe explains what Stripe handles and what remains your software's job.

The five terms worth knowing, and no more

The rest is for your technical partners. What is for you are the questions at the end of this guide.

What APIs change for your business software

What they bring

• No more retyping: data entered once flows between tools. Less time wasted, and above all fewer copying errors.
• One source of truth per piece of data: a customer lives in one master system and the others read it. No more three different addresses for the same customer.
• A smaller custom application: no need to rebuild accounting, payments or e-signature. Your application does what is specific to you and relies on specialist tools for the rest.
• Real-time processing: a payment received releases an order within seconds, without waiting for someone to check the bank statement.

What they demand

• A dependency: if the vendor changes or retires its API, the integration has to follow. Good vendors announce version changes and give notice; others less so.
• Usage limits: calls per second or per day, sometimes charged above a threshold.
• Data in transit: every transfer of personal data to a third-party service must appear in your GDPR records and be covered by a data processing agreement with that provider. Our GDPR checklist lists what to document.
• Keys to protect: a leaked API key is an open door to your data. It is stored on the server, never in a spreadsheet or an email.

What drives the cost of an integration

There is no public price for "an API integration", and we will not invent one: the same connector can take two days or two months. What makes the difference:

The first cost item is almost always error handling: what happens if the platform does not respond, if a customer exists twice, if an invoice is rejected? A quote that only mentions "connecting the API" underestimates the work. Our guide to integrating a custom application with an ERP goes through these questions, which apply to any tool.

The second, often forgotten, is maintenance: APIs evolve, and an integration needs monitoring. Plan for alerts when a sync fails, and for someone to read them.

When you do not need an API integration

A custom integration is not always the right answer:

• a file export once a week is enough when the data does not need to be fresh;
• a no-code connector (Zapier, Make, n8n) links two mainstream products well when both are already supported and the rules are simple. Our comparison of n8n and custom code helps you choose;
• a tool with no API cannot be integrated cleanly. If the exchange is essential, it may be the tool that needs replacing.

Six questions to ask before buying software

Before subscribing to any off-the-shelf product, ask these six questions. They decide what you will be able to do with it later:

1. Is there a public, documented API? Ask for the link.
2. Is it included in your plan, or reserved for a higher tier?
3. Does it cover reading and writing the data you care about?
4. Are there webhooks to be told about changes?
5. Is a sandbox provided for testing?
6. Can you export all your data when you leave? Our guide to a vendor lock-in exit plan explains why this matters.

And if you are commissioning custom business software, ask the reverse question: will your application have its own documented API, so that your future tools can connect to it?

Where to start

1. List the retyping done in a typical week: which data, copied from which tool to which tool, by whom.
2. Name the master system for each type of data (customers, products, invoices).
3. Check the APIs of the tools involved with the six questions above.
4. Start with a single flow, the one that causes the most errors.

If that flow runs through an application that still has to be built, see it before you pay for it. We build a free visual prototype, presented on a video call within 5 business days, so you can see where each piece of data arrives and where it comes from. Our article see your software before you pay explains how it works.