APIs and Integrations at a Recognition Level

At some point in every project meeting, someone says “don’t worry, we’ll integrate via the API,” and everyone nods. This module is so that your nod is real. You already know the four big systems from modules 2–5 — CRM, ERP, HRIS, ITSM — and module 6 covered how people get into them. This one covers how software gets into them.

An API (application programming interface) is a system’s front desk for other software. Think of a restaurant: you never walk into the kitchen, rearrange the pans, and cook your own meal. You hand the waiter a structured order — “table 12, two of item 47, no onions” — and a plated dish comes back. An API is exactly that: a published menu of requests a system will accept, without ever letting outsiders touch its insides. A real request looks about as thrilling as “give me all invoices for customer 4711” — and the ERP answers with a neat list, the same way, every time, a million times a day. An integration is what you get when two systems are wired together through their APIs so data moves between them without a human re-typing it: a deal closes in the CRM, and an order appears in the ERP on its own.

The front desk and the adapter in between

Two systems rarely speak the same dialect, so most integrations put an adapter layer in the middle: middleware, sold as cloud services under the name iPaaS (integration platform as a service). MuleSoft is a famous heavyweight example; Zapier and Microsoft Power Automate are the lightweight end that non-developers can click together. Whatever the brand, the job is the same: take a message from system A’s API, translate the field names and formats, and deliver it to system B’s API — plus queue it, retry it, and log it when something goes wrong. If you did the AI & Automation course, this is the plumbing your automations actually run on.

Push, pull, and the overnight job

How does system B find out something happened in system A? Two patterns. Polling is “are we there yet?” — B asks A every few minutes whether anything changed. A webhook is “call me when it happens” — A pushes a message to B the instant the event occurs. Webhooks are faster and cheaper; polling is simpler and older. Then there’s timing. A real-time integration moves each record within seconds. A batch integration saves everything up and moves it in one big job — classically overnight. That overnight job is why yesterday’s sales appear on this morning’s dashboard, and why the report you run at 9 a.m. Monday doesn’t include the deal closed at 9:05. Nobody is hiding anything: the data simply travels by night train, usually into a data warehouse — the world the Azure Data for Non-Engineers course walks through.

“The integration is down” — and why “just connect them” is a project

When someone announces “the integration is down,” here’s the odd part: both systems are usually fine. The CRM is up, the ERP is up — the pipe between them broke. New records pile up in a queue on one side, and when the pipe is fixed, they get replayed — pushed through in order — which is why things “catch up” a few hours after the fix rather than instantly. Now, why is “can’t we just connect them?” a bigger ask than it sounds? Four reasons. Field mappings: is “Customer Name” in system A the same as “Account” in system B — and what happens to the field B has that A doesn’t? Error handling: what should happen when a record is rejected at 2 a.m.? Permissions: the integration needs its own account and rights, and security will ask hard questions (module 6 again). Versions: vendors change their APIs, and every change can quietly snap the pipe. None of this is exotic — it’s just detail, and detail is what estimates are made of.

The next time someone says “we’ll integrate via the API,” ask three questions: which direction does the data flow, how fresh does it need to be (real-time or overnight is a cost decision, not a technical accident), and what happens when a record fails? You’ll sound like you’ve done this before — because now you know the only three things that usually matter.

Spot it: what’s actually going on here?

Why it matters

APIs and integrations are the connective tissue of every system you’ve met in this course — the CRM-to-ERP order flow, the HRIS feeding the identity system from module 6, the ITSM tool logging it all. Understanding the pipe means you can ask useful questions instead of nodding blankly, and you can tell a broken integration from a broken system — a distinction that saves real hours in real incidents. It also sets up the finale: module 8 is about what happens when the pipes don’t get built, and why “the system doesn’t talk to the other system” is the most expensive sentence in corporate life.