Request a demo

Integrations and Technology

What Is an Integration API? A Guide for Business Decision-Makers

An integration API lets your other systems create records in your business software and hear about changes, without exports and retyping. What it does, what it costs to build on, and what to ask before you commit.

By Flux Editorial TeamPublished 4 min read

Illustrative example with fictional data.

An integration API is a documented way for one piece of software to talk to another without a person in the middle. Instead of exporting a spreadsheet from your enrolment system every Friday and retyping it into your billing system, the two systems exchange the records directly. This guide is for the person who signs off the project, not the person who writes the code.

The problem it solves

Most growing businesses run more than one system. A school has a student portal and a billing system. A training provider has a booking website and an accounts package. A logistics company has a dispatch tool and an invoicing tool. Each knows something the others need.

Without an integration, the gap is filled by people:

  • someone exports a list of new customers and creates them again in the finance system;
  • someone checks the finance system for who has paid and updates the portal by hand;
  • someone notices a customer was created twice, months later, when their statement looks wrong.

An API replaces that manual copying with a defined, automatic exchange.

What "API" actually means

API stands for application programming interface. In practice, for business software, it's a set of addresses your developer's code can send requests to, each doing one job:

Request What it does
Create a customer Adds a customer record, with a reference to the same customer in your own system
Raise an invoice Creates an invoice for a customer, with its lines
Read an invoice Returns its current status: approved, paid, overdue
Get a statement Returns everything a customer has been billed and has paid

Most modern APIs are REST APIs: requests travel over HTTPS, the same secure connection a browser uses, and data is exchanged as JSON, a plain text format both sides can read.

The other half of an integration is the webhook. An API is your system asking questions; a webhook is the other system telling you something happened, such as "this invoice was just paid". Our guide to webhooks covers them in detail.

A worked example: a training academy in Garki

An academy in Abuja takes course bookings on its website and bills through its finance system. With an integration:

  1. A learner books a ₦450,000 course on the website. The website's code calls the API to create the customer, using the website's own booking reference so the two systems can always find each other.
  2. The website raises the invoice through the API. In a well-designed system, that invoice still goes through the finance team's normal approval before it's sent.
  3. The learner pays online. The finance system sends a webhook saying the invoice is paid.
  4. The website receives it and opens up the course materials. Nobody checked a bank alert.

The finance manager's month-end is unchanged, except that every booking is already in the finance system with a matching reference.

What it costs

Calling an API is rarely where the cost sits. Building on one is. Budget for:

  • Developer time to build and test the connection: the first integration usually takes longest.
  • Somewhere for the code to run, usually the system that already hosts your website or portal.
  • Ownership after launch. Someone has to notice when a connection fails and fix it. This is the cost most often forgotten.

If you don't have a developer, the honest answer is that an API may not be your first step. Importing from Excel can cover a lot of ground until volumes justify the build.

Questions to ask before you commit

Put these to any software vendor whose API you're considering:

  1. Is the documentation public? If you can't read it before buying, expect surprises after.
  2. Does work created through the API follow the same controls as work created by people? An invoice that skips approval because it came from code is a gap in your controls. See what an approval workflow is.
  3. Can each connected system have its own key with limited permissions? A booking website shouldn't be able to read payroll. Our guide to API security basics explains scopes.
  4. What stops duplicates when a request is retried? Networks fail, and a retry shouldn't create a second invoice. See avoiding duplicate records.
  5. Are webhooks signed, and are they retried if your system is down?
  6. Is there a limit on how many requests you can make, and what happens when you hit it?
  7. Is there a test environment? If not, ask how they recommend you test safely.

How Flux helps

Flux has a REST integration API for customers, invoices, receipts and statements. Invoices raised through the API go into the same approval workflow as invoices raised in the app, so the integration doesn't bypass your controls. Organisation admins create API keys with only the scopes each system needs, webhooks are signed, and PDF and payment links are signed and expire. There's no separate test environment yet, so the documentation asks integrators to get in touch before building. Start with the Developers page, then read the full reference at developers.flux-erp.app.

From the blog