An application programming interface (API) is an agreed way for one software system to request information or perform allowed operations through another system. It is one of the main tools for connecting websites, mobile apps, accounting platforms, payment systems and internal business software.
You do not need to write code to make a good API decision. You need to understand what information must move, who may access it, what happens on failure and who is accountable for the results.
1. What an API actually does
Consider a customer portal that displays invoice status. The portal can request information from an accounting system through a permitted interface. The accounting system checks authentication and authorization, finds the relevant invoice and returns an agreed response.
A simplified conceptual exchange:
GET /api/v1/invoices/INV-1024
Authorization: Bearer <access-token>{
"invoice_id": "INV-1024",
"currency": "USD",
"status": "paid",
"amount": 125.00
}Illustrative data and endpoint only. Never place real access tokens in documentation or logs.
The key point: the portal should only see invoices the authenticated visitor is entitled to access. Checking that a user is logged in is not enough; the API must check access to each requested record.
2. Distinguish an API from an integration
An API is an interface. An integration is the operating arrangement that uses that interface: field mappings, credentials, permissions, retries, monitoring, reconciliation, incident response and business ownership.
Two applications may both advertise “API access” and still require substantial integration effort because identifiers, definitions or supported operations differ.
3. Common API styles and patterns
REST over HTTP commonly exposes resources through URLs and standard methods such as GET and POST. GraphQL lets clients request structured data according to a schema. Webhooks notify another service when an event occurs, whereas polling repeatedly asks for updates. Message-driven integrations support decoupled asynchronous processing.
Do not choose based on trendiness. For ordinary business integration, a stable vendor-supported API with clear documentation and support commitments is generally preferable to a more fashionable but poorly maintained option.
4. Security decisions every buyer should request
At minimum, clarify how callers authenticate, how authorization is applied per record, whether access can be revoked, how secrets are stored, and whether sensitive data is transmitted with suitable protection.
OWASP’s API Security Top 10 identifies risks such as broken object-level authorization, broken authentication, unrestricted resource consumption and security misconfiguration. A developer should be able to explain how the actual implementation addresses relevant risks.
5. Plan for errors, duplicates and changing data
An API can fail due to connectivity, unavailable servers, revoked permissions, invalid data or rate limits. A payment or order submission may succeed server-side even when the client never receives the response. Blindly retrying can cause duplicates unless idempotency has been designed.
Ask suppliers for a failure demonstration. What does the user see if synchronization is delayed? Is the work lost? Can an administrator inspect failed transfers without accessing sensitive raw payloads unnecessarily?
6. Confirm commercial terms and limits
Vendor API access may be included with a subscription, sold separately or subject to usage fees. Review rate limits, support hours, versioning policy, data export rights and service-level obligations where available. A technically feasible connection can still be commercially unsuitable.
If the API is a strategic dependency, plan for contract changes and migration. Store locally the information needed for permitted historical records, not uncontrolled copies of sensitive data.
7. How to brief an integration provider
Provide this short statement:
“When [business event] happens in [source system], we need [specific information] to become available in [destination] within [acceptable delay]. [Named team] owns the source. The receiving system may [read/write permitted actions]. If transfer fails, [expected user and recovery behavior].”
That description is much more actionable than “please integrate our systems.”
API readiness checklist
- A business process and information owner are identified.
- The source system provides a supported interface.
- Required fields and permissions are documented.
- Rate limits, costs and versioning are understood.
- Authentication and record-level authorization are designed.
- Duplicate requests and failures are handled.
- Logging does not expose secrets or personal data unnecessarily.
- Reconciliation and support ownership are defined.
Frequently asked questions
Is an API the same as a database? No. A database stores and manages information; an API is a defined interface through which a system may expose capabilities or data.
Can APIs work offline? A remote API generally requires connectivity at the time of communication. Local work can be queued and synchronized later where the business rules permit it.
Does every integration require custom code? No. Some vendors provide supported connectors or configuration. More complex rules often require custom integration engineering.
Can an API write into an industrial PLC? Some industrial interfaces support writes, but this is not inherently appropriate. Approved read-only data access and machine-control authority must remain separate.
Related reading
See Connecting Business Systems, Offline-First Software and Excel vs ERP vs Custom Software.
