An API (application programming interface) is a published contract that lets one program request actions or data from another in a predictable format. In business integrations, APIs are how ecommerce platforms, accounting systems, CRMs, and custom apps speak without human copy-paste.
At a high level, a client sends a request to an endpoint; the server authenticates the caller, applies rules, and returns a structured response—often JSON—plus a status that indicates success or failure. Understanding that lifecycle helps buyers evaluate vendors and interpret integration status reports.
The building blocks
- Endpoints — URLs that represent resources (customers, invoices, products)
- Methods — common HTTP verbs such as GET (read), POST (create), PUT/PATCH (update), DELETE (remove)
- Authentication — API keys, OAuth tokens, or signed requests proving identity
- Payloads — the data sent or returned
- Status codes and errors — machine-readable outcomes clients must handle
- Rate limits and pagination — rules that shape how much you can read or write per window
Request lifecycle
API request lifecycle
- Client prepares authenticated request
- Request hits the correct endpoint
- Server authorises and validates input
- Business logic runs against data stores
- Structured response returns to client
Synchronous calls vs event-driven patterns
Many integrations poll or call APIs on a schedule. Others react to events via webhooks, where the source system pushes a notification when something changes. Both still rely on API concepts; they differ in who initiates the conversation. See API vs webhook.
Why documentation and sandboxes matter
Reliable integration depends on clear docs, stable versioning, and test environments. Without a sandbox, teams either test in production (risky) or guess (also risky). Rate limits and pagination rules are not footnotes—they shape architecture. Ask vendors for sample payloads of the documents you actually use, not only a “hello world” customer create.
Practical implications for business buyers
When evaluating software, ask whether a real API exists, what authentication it uses, whether webhooks are available, and how the vendor communicates breaking changes. “We have an API” is the start of diligence, not the end. Also ask who supports the API commercially—community-only forums are a different risk profile than a documented enterprise channel.
Reading errors like an engineer (and a buyer)
A 401 usually means authentication failed; 403 means authenticated but not allowed; 404 means resource missing; 422/400 often means validation problems; 429 means rate limited; 5xx means server-side trouble. Buyers do not need to code, but understanding these categories helps interpret integration status reports and decide whether the fix is credentials, mapping, or vendor downtime.
Versioning and breaking changes
APIs evolve. Prefer vendors who version endpoints and publish changelogs. Your integration should pin to a version intentionally and schedule upgrades rather than auto-following every breaking change unprepared. Budget time after major vendor releases to re-test critical document types.
Idempotency in plain language
If a network glitch causes a retry, the system should not create two invoices. Idempotency keys or upsert logic make retries safe. Ask vendors how duplicates are prevented—and verify the answer with a deliberate double-submit test in sandbox.
A concrete walkthrough
Your middleware needs to create a sales invoice in accounting. It authenticates with OAuth, POSTs a JSON payload with debtor code, lines, and tax codes, then receives either a document ID (success) or a validation error (unknown item). On timeout, it retries with the same idempotency key so a late success plus a retry does not double-post. That entire conversation is “how an API works” in production—not a textbook diagram.
FAQ
REST vs GraphQL vs SOAP—does it matter to the business?
It matters to implementers. For sponsors, focus on reliability, documentation quality, sandbox access, and whether the API can express the business documents you need.
What is OAuth in plain language?
OAuth is a common way to grant limited access without sharing your main password. Your app receives a token with scoped permissions; tokens can expire and be refreshed. It is safer than embedding a permanent master password in code.
Why do integrations fail even when the API is “up”?
Validation rules, missing master data, rate limits, and permission scopes cause many failures. The HTTP service can be healthy while your specific payload is rejected.
Do we need developers to use an API?
Someone technical must implement and maintain the connection. Business owners still decide mappings, document types, and exception handling. Treat API access as a product capability with joint ownership.
How is this different from a file import?
File imports are usually batch and human-triggered. APIs support programmatic, repeatable create/update/read with clearer error contracts—better for ongoing API integration.
Related concepts
Business practice: what is API integration. Push notifications: what is a webhook. Comparison: API vs webhook. Field translation: what is data mapping.