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 and authorization. The request carries a credential, such as an API key or an OAuth access token, that the provider uses for authentication: establishing who or what is calling. An API key often identifies an application or account rather than a particular person. The provider then makes an authorization decision: whether that caller may perform this action on this particular data, based on things like the token's scopes, the caller's role and who owns the record. A request without valid credentials is typically refused with status 401; one that is understood but not permitted, with 403.
- 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 are notifications rather than a separate kind of API. You register a URL with the provider, and when an event happens, such as a completed payment, the provider sends an HTTP request (usually a POST) to that URL, so your system does not have to keep asking. Your endpoint should verify that each request really came from the provider, for example by checking its signature, respond quickly, and cope with retries, duplicate deliveries and events that arrive out of order.
- 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 receives the booking system's webhook, the notification it sends when a job is complete, checks that the notification is genuine and has not already been handled, 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. So do authorization checks on every request: the first risk in OWASP's 2023 API Security Top 10 is broken object level authorization, where an API returns or changes a record without checking that the caller is allowed to access it.
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)
- RFC 6749: The OAuth 2.0 Authorization Framework, IETF (RFC Editor) (accessed November 9, 2026)
- RFC 9110: HTTP Semantics, IETF (RFC Editor) (accessed November 9, 2026)
- OWASP Top 10 API Security Risks – 2023, OWASP (accessed November 9, 2026)
- Introduction to API keys, Google Cloud (accessed November 9, 2026)
- Receive Stripe events in your webhook endpoint, Stripe (accessed November 9, 2026)
- About webhooks, GitHub Docs (accessed November 9, 2026)