Quick definition
An API (application programming interface) is a defined way for one piece of software to request data or actions from another. It works like a contract: the requesting program asks in an agreed format and gets a predictable response back.
Business software rarely works alone. A website might take payments through a payment gateway, look up shipping rates from a carrier, and send new customers to an accounting system. Each of those connections usually runs through an API.
An API is a set of rules a program offers so that other software can interact with it, as opposed to a screen designed for people. MDN describes it as a contract between the application offering it and the software that uses it. A useful comparison is a service counter: you cannot walk into the kitchen, but you can place an order in a defined way and get back what you asked for.
How a typical web API works
- Request. Your system sends a request over the internet to an address the provider documents, for example "create an invoice" or "get order 1042," along with any required data.
- Authentication. The request carries a credential, such as an API key or access token, proving it is allowed to do this.
- Processing. The provider checks the request, does the work, and applies its own rules and usage limits.
- Response. It sends back a result, commonly formatted as JSON, with a status code that shows success or the reason for failure.
Kinds of APIs you will hear about
- Web APIs connect systems over the internet. Most business integrations use these.
- REST is an architectural style many web APIs follow. It was described by Roy Fielding in 2000 as a set of constraints, such as stateless requests and a uniform interface.
- Webhooks reverse the direction. Instead of your system asking repeatedly, the provider notifies your system when something happens, such as a completed payment.
- Built-in APIs exist inside software too, such as the features a web browser offers to the scripts on a page.
Why APIs matter for custom software
APIs let a business connect the tools it already uses instead of re-typing data between them. A booking system can create a customer in the accounting package; an online store can check stock in a warehouse system. Well-designed integrations also make it easier to replace one tool later without rebuilding everything around it.
Limitations
An API only offers what its provider chooses to expose, and providers can change, restrict or retire APIs. Many enforce usage limits or charge for access, and every integration has to cope with errors and outages. Integrations therefore need maintenance, monitoring and careful handling of credentials.
A practical example
A landscaping company takes bookings on its website, then re-enters every completed job into its accounting software to send an invoice. Mistakes creep in and invoices go out late.
A custom integration listens for the booking system's notification that a job is complete, then uses the accounting software's API to create the customer if needed and raise the invoice. Staff now review invoices instead of typing them, and the integration logs every request so failures can be spotted and retried.
Why it matters
APIs are what turn separate software products into a working system. They reduce manual data entry, cut errors, and let information move in minutes instead of at the end of the week. When choosing software, whether it offers a documented API is a practical question about how well it will fit with the rest of your business.
Common mistakes
- Putting secret keys in public code. Keys embedded in a website's browser-side scripts or committed to a public repository can be copied and misused. Keep secrets on the server.
- Assuming every call succeeds. Integrations that ignore errors and usage limits fail silently when a provider is slow, down or throttling requests.
- No logging. Without a record of requests and responses, it is hard to work out what happened when data goes missing.
- Relying on undocumented behavior. Features the provider does not document can change without notice.
- Testing against live accounts. Many providers offer a sandbox. Testing on a live account can create real invoices, charges or emails.
API vs. REST
The two terms are often used interchangeably, but they describe different things.
| API | REST | |
|---|---|---|
| What it is | Any defined interface that lets software interact with other software | An architectural style for designing networked APIs |
| Scope | Web services, operating systems, browsers, code libraries | Networked APIs, usually over HTTP |
| Example | A payment gateway's interface for charging a card | An API where requesting /orders/1042 returns that order |
| Relationship | A REST API is one kind of API | Not every API is RESTful; other styles exist |
Frequently asked questions
Is an API the same as an integration?
No. The API is the interface a product offers. An integration is the code or service that uses one or more APIs to connect systems and move data between them.
Are APIs secure?
That depends on how they are built and used. Encrypted connections, strong authentication, credentials limited to only what the integration needs, and careful handling of keys all matter.
Do I need a developer to use an API?
Not always. Many tools offer ready-made connectors that use APIs behind the scenes. Custom workflows, unusual data or business rules generally need development.
Sources
- API (glossary), MDN Web Docs (accessed November 9, 2026)
- REST (glossary), MDN Web Docs (accessed November 9, 2026)
- Architectural Styles and the Design of Network-based Software Architectures, Chapter 5: Representational State Transfer (REST), Roy T. Fielding, University of California, Irvine (accessed November 9, 2026)