What is an API? A 20-minute audit for software that doesn't talk

If your order tool and your ERP both expose an API, an integration could be designed to move the reseller order that today gets re-typed from email as structured data: order number, line items, quantities, unit prices and delivery date. That design only exists if there is a defined way to capture the emailed order, and if the provider builds the mapping, validation and human-approval workflow around the transfer. Inside that design, the human job could shift from typing every line to approving exceptions. That is the whole promise in one sentence, and the rest of this page explains when it is real and when it is not.

This article comes from Niro Digital, an agency that sells AI automation and custom software work. It will not pretend an API fixes business logic, will not invent a price for connecting your systems, and will not send you to a contact form at the end. The useful next step is the published project library. First, the definition.

An application programming interface (API) is a set of features and rules inside a software program that lets another program interact with it. MDN's glossary describes it as a contract between the application offering the API and the outside software or hardware that uses it. It is not a screen a person works with and not a file someone exports and emails around. The cleanest picture is MDN's plug-socket analogy from its web APIs tutorial: an application plugs into the API socket instead of wiring itself directly into the underlying system.

A human user interface — the screen where an employee clicks and types — is built for a person. An API is built for another program. A spreadsheet export is a frozen copy of data at one moment.

Imagine an order that arrives by email and is retyped into the ERP — the same flow this article uses as its running example. If both tools expose an API, an integration could send the order as structured data: order number, line items, quantities, unit prices and delivery date travel labelled, rather than as prose a person must interpret. This is an illustration, not a claim about a shipped order-to-ERP project at any named company. It shows the shape of a supervised transfer: data moves automatically, and anything unexpected stops for a person instead of being booked twice or dropped.

The published example of that shape is internal product work, not a client order integration. Niro Digital's case study of its own content-agent platform reports 14 processing stages and 15 validators before an article is finished, at $0.37 per finished article. A verification gate is a deliberate check an output must pass before it counts as done, and the platform runs those checks before it calls work finished. That problem is not order re-entry, and $0.37 is not a price for your integration — it is evidence that automated output can be checked before it is treated as done. You can read the full content-agent platform case study and judge whether the method is real.

One mechanism deserves a plain name. An event notification, often called a webhook, is a push: when a defined event happens, one system sends a notice to an address belonging to the other system, so the receiving side can trigger its next step. Stripe's documentation describes webhooks as a way for a system to push event notifications instead of requiring the receiving side to keep polling for changes — the technical difference between "another program is watching" and "another program is asking repeatedly".

Before and after, side by side — illustration only:

The takeaway is not that the employee disappears. Inside the illustration, the employee stops being the data-entry step and becomes the approval step.

When scheduled export/import is enough — a decision checklist

This comparison is a decision checklist, not a measured rule. Scheduled export/import may be sufficient when the transfer is infrequent or happens in batches, a delay of hours or a day is acceptable, and errors are easy to spot and correct in the receiving system. Consider a live integration instead when the same data moves many times a day, people are retyping the same fields, or delays and typing errors already have visible consequences — the failure symptoms the audit asks you to write down.

The plug-socket analogy is helpful, then it runs out. A wall socket has one standard shape; an API is the specific set of features and rules inside one particular program, so it is not a universal interchange. Whether two named products can exchange the audited fields is a per-pair, per-field question, and the answer has to be checked against each product's contract. That is why the audit begins with exact product names.

This exercise starts with one painful manual transfer, not an integrate-everything programme. Naming one transfer, a pair of systems and today's failure symptoms gives you and any provider something concrete to compare later. The output is one written card. It takes about 20 minutes and no developer.

Step 1: pick the single manual transfer that hurts most today

Choose a transfer that happens repeatedly, requires re-keying, and has visible consequences when it goes wrong. Write it in one line. If it needs a paragraph, it is too broad. For the rest of this article, the example is: reseller orders arrive by email and are retyped into the ERP.

Step 2: name the two systems involved

Write exact product names, not "our ordering tool" and "the ERP". A provider can only check API documentation once the actual products are named. If more than two systems are involved, pick the pair where the failure hurts most.

Step 3: list the exact data fields that must move

"Sync everything" is not a scoping answer. For the order example, the fields are: order number, order lines, quantities, unit prices and delivery date. This field list becomes the mapping your future provider will build, so it is worth getting precise before any sales conversation.

Step 4: write down today's failure symptoms

The failures you already see are the acceptance criteria. Late order confirmations, typing errors, duplicated orders, stock numbers that do not match — write them down. An integration project with no written symptoms has no pass or fail test.

Step 5: decide who approves before an irreversible action

An irreversible action is one that cannot be undone without cost or conflict — booking an order into the ERP is a good example. Name the person who must confirm the record is correct before that action runs. This is a human approval gate: a deliberate step where a named person, not the system, gives the final yes. Niro Digital's published automation doctrine states the principle plainly: "We never trust model output blindly." Automated output is treated as a claim that must pass checks and human approval before it counts as done.

Step 6: plan the rollout before the new flow replaces the current one

Name the employee whose work changes — in the example, the person who retypes orders. Write down the approval and exception process when the automated flow cannot proceed, the training that employee needs, and how the new workflow will be tested in parallel with the current one before it replaces it.

Worked example: a completed audit for a reseller order entering the ERP

For the order-to-ERP example, the completed card looks like this:

• The one manual transfer that hurts most today: reseller orders are retyped from email into the ERP.
• The two systems involved: [name your order/email tool] and [name your ERP].
• The exact data fields that must move: order number, order lines, quantities, unit prices, delivery date.
• Today's failure symptoms: order confirmation can take up to two days; typos reach stock and invoicing; month-end reports are assembled by hand.
• The person who must approve before an irreversible action: the operations lead, before an order is booked.
• Rollout plan: the operations lead takes the approval step; the new flow runs in parallel with the current one for a defined period before it replaces the retyping.

This is an illustration, not a claim about any named ERP. If you cannot fill in the bracketed product names, that is the first thing to fix.

Copy the blank version and fill it in:

Compare three candidates before you commit

Keep the audit honest by writing down both alternatives you are not choosing first.

Failure is not an edge case; it is a design input. Stripe's published webhook behaviour is a useful concrete example because it is documented. If the receiving system cannot process an event, Stripe automatically re-sends undelivered events for up to three days. It attempts delivery with exponentially increasing waits, and those retries can produce duplicate deliveries, so the receiving system must be designed to avoid double-processing an event. Network outages can cause events to be lost or to arrive out of order.

There is also a recovery limit. Stripe's documentation says events that were never successfully delivered can be re-fetched manually from its list-events API, but that API only returns events created in the last 30 days. After that window, an undelivered event can no longer be recovered through the API. A silent failure can become permanent if nobody is watching.

Those failure behaviours are what to test a proposal against. Ask any prospective provider whether the proposed integration will alert a named person when a transfer fails, guard against duplicate processing, monitor retries and delivery, keep an exception queue for anything unexpected, and require human approval before an ambiguous or irreversible action is booked.

This article gives no indicative price or timeline for an order-to-ERP integration, because no approved cost-and-effort evidence for your scenario is available — and we will not invent a figure. What we can tell you is how to treat a quote: ask any provider to write down the assumptions behind it, including which systems and fields they checked, how failures and retries are handled, and how testing, monitoring and alerting are covered. Ask for the assumptions before the number.

The MDN definition gives you the boundary: an API is a set of features and rules that let one program interact with another. It is a contract between programs — and a contract is not a set of business judgements. When a proposal sounds like the integration will make the decisions, ask where the checks sit and which person approves the exceptions. The audit's approval step marks that place.

When you sit down with a vendor or an agency, do not fake technical vocabulary. Ask these eight questions in plain words:

1. Does each system really expose an API for the data fields we listed, or is this export/import?
2. What happens when a call or event fails?
3. Who gets alerted, and how quickly?
4. How is duplicate processing prevented?
5. At what point does a human approve before an order is booked?
6. Can the integration be paused if we need to stop it?
7. If we change a tool or provider, who owns the integration code, configuration, documentation and credentials, and what records will we receive so another provider can maintain or replace it?
8. Which data will the integration access, where will it be stored and processed, how is access controlled, and how are credentials and access revoked when we stop using the provider or integration?

Each question maps to a failure behaviour from earlier. Use the answers to compare proposals side by side.

This article is written by Niro Digital, a digital agency whose four main services are AI automation, custom software development, recruiting advertising, and lead generation advertising. That means we sell this type of work, and you should weigh the advice accordingly. If you finish the audit and want to understand how a provider would map your workflow into supervised automation — automation that runs inside checks and approval gates a person defines — the AI automation service page explains the engagement. The better next step before any conversation is evidence: read the project library and check whether the published work matches the claims. Before you talk to anyone, including us, look at how we publish the work we ship.