What is an API in Programming?

Two programs written by different teams, in different languages, still manage to exchange data all day long. An API is what makes that possible. One program asks for data or an action, another answers, and neither side ever reads the other’s source code.

The pattern holds whether you’re loading a mobile app, paying at a checkout, or watching a cloud dashboard refresh. A client sends a request. A server sends back a response.

There’s money in it, too. Among organizations that generate revenue from their APIs, 74% generate at least 10% of total revenue this way, according to Postman’s 2025 State of the API Report. Fully API-first teams push that share even higher, with 43% generating more than a quarter of revenue through their APIs.

What Is an API

The rules come first. An API sets out what you can ask for, how to ask, and what shape the answer will take, so one piece of software can pull data or trigger functionality from another without either side reading the other’s code.

Application Programming Interface is what the acronym unpacks to. It’s a standard for how software talks to software, not a program you run on its own.

Pull a weather forecast into a mobile app, or charge a card on a checkout page. In both cases an API handles the exchange between the two systems.

The frontend application a person actually looks at fires off the request. A backend service sitting somewhere else processes it and sends data back.

That handoff is the whole point. An API defines the contract for the exchange, which is how two teams, sometimes two companies, build software that works together without ever seeing each other’s codebase.

API vs SDK vs Web Service

Mixing these three up causes real confusion in planning meetings, and it happens constantly.

• An API is the set of rules for requesting data or functionality. It isn’t tied to a language or a format.
• An SDK is a packaged bundle of tools, code libraries, and usually an API wrapper for one specific platform.
• A web service only works over a network, using web protocols like HTTP. Narrower thing.

Every web service is an API. The reverse doesn’t hold, since plenty of APIs run locally between programs on the same machine with no network anywhere in the picture.

Types of APIs by Access Level

Who is allowed to call an API changes almost everything about it. Public, private, partner, and composite each carry different expectations around authentication and how much documentation ever gets published.

Public APIs

Anyone can register and start calling a public API, usually after grabbing a key and agreeing to a published rate limit.

• Documentation sits out in the open, no sales conversation needed
• Access is self-serve, often with a free tier
• Terms of service govern usage instead of a private contract

Google Maps is the textbook case. Sign up for a key, and you can drop a map into an app or geocode an address the same afternoon.

Private APIs

Private APIs stay inside the company. Nobody outside gets credentials, and there’s no sign-up form to find.

They exist because large organizations run internal systems that constantly hand data back and forth, and a private API is less work to maintain than a shared database everyone writes to.

• No public documentation required
• Access runs through internal authentication

Partner APIs

Partner APIs land between the other two. Access opens once a business agreement gets signed, not once somebody fills in a form.

Salesforce exposes partner-level API access to approved integration vendors listed on its AppExchange marketplace, a common structure for this access tier.

Postman’s 2025 State of the API report found that 65% of organizations now generate direct revenue from their API programs, and partner agreements account for a real share of that.

Composite APIs

One request, several calls bundled inside it, one combined response coming back. That’s a composite API, and it exists so a client isn’t making five separate round trips to fill one screen.

• Fewer network calls for the client to make
• Common in microservices architecture, where a single user action might touch five different services

On a phone with a weak signal, every round trip you cut is latency the user actually feels.

How Does an API Work

Request goes out, response comes back. A client hits a defined endpoint, the server processes what it receives, and an answer travels back down the same path.

That exchange rides on a transport protocol, and on the modern web that means HTTP or HTTPS almost without exception.

Older browser-based apps used Ajax to fire these requests in the background without reloading the page, and that same request-response pattern still underlies most API traffic today.

Endpoints and Requests

An endpoint is a specific URL where an API can be reached, and each one usually maps to a single resource or action.

• The endpoint URL is the address the request goes to, something like api.example.com/users
• Headers carry metadata alongside the request, most often the authentication token
• Query parameters filter what comes back, appended to the URL as ?limit=10
• The response payload is the data itself, typically JSON

Every call needs at least an endpoint and a method. Headers and parameters shape the rest of what you get.

HTTP Methods and Status Codes

Day-to-day API work comes down to a small handful of HTTP methods.

Status codes let the client know what happened without parsing the response body first.

A 200 means success, a 401 means the request lacked valid credentials, and a 404 means the endpoint or resource doesn’t exist.

API Data Formats

JSON and XML cover nearly all API traffic, and JSON is what new builds reach for by default.

JSON is lightweight, readable, and native to JavaScript, which is most of the reason it took over as REST pushed older architectures aside.

XML is older and a lot more verbose. It’s still everywhere in enterprise systems built on XML-based protocols like SOAP.

A raw JSON response usually arrives minified into one long line with no spacing, so developers run it through a formatter before trying to read it.

Data serialization, the process of converting an object in memory into a transmittable format like JSON, happens on every single API call in both directions.

The GitHub API returns JSON by default on every endpoint, a fairly typical choice for a modern public API built on REST.

API Architectural Styles

Postman’s 2025 State of the API report found that 93% of respondents use REST as the architecture behind their APIs, making it the default for web and mobile backends alike.

REST isn’t the only option though, and the right architecture depends on the kind of data being moved and how fast it needs to move.

REST

Roy Fielding defined Representational State Transfer in his 2000 doctoral dissertation, and API design has been anchored to it ever since.

It’s stateless, so any server can handle any request. Responses cache well, which cuts server load. And because it runs on plain HTTP methods and JSON, almost every language can consume it without a special library.

The weaknesses show up on complex screens, where REST tends to over-fetch or under-fetch. Endpoint count also creeps up as the API surface grows, and somebody has to maintain all of them.

SOAP

Strict XML messaging, a formal contract defined in a WSDL file, and validation that catches malformed data before it moves money or medical records. That combination is exactly why SOAP never disappeared from banking and healthcare.

Postman’s 2023 State of the API Report put SOAP usage at 26% of respondents, down from 34% the year before.

The cost is weight. XML payloads run heavier than JSON, and the learning curve is steeper than REST by a wide margin.

GraphQL

GraphQL flips the usual model. Rather than the server deciding what a response contains, the client writes a query naming exactly the fields it wants.

• One request can pull data that would take several REST calls to assemble
• No more over-fetching fields nobody uses
• Caching gets harder, since every request runs through a single endpoint

Facebook built GraphQL internally before open-sourcing it in 2015, largely to fix the over-fetching problems its own mobile apps kept running into.

gRPC and WebSocket

gRPC swaps JSON for Protocol Buffers, a binary format that shrinks payload size and speeds up communication between services.

Low latency at high call volume is the payoff, which is why gRPC shows up inside microservices architecture far more than at the public API layer. Debugging is where you pay for it. Protocol Buffers aren’t human-readable in a browser the way JSON is, so you need extra tooling to see what’s going on.

WebSocket takes another approach, holding a connection open so either side can push data without a fresh request. Chat apps, live dashboards, multiplayer features. That open connection does cost more server resources per active user than a stateless REST call.

API Authentication and Security

Every incoming request gets checked before any data moves.

Salt Security’s 2025 State of API Security report found that 99% of organizations experienced an API-related security problem in the past year.

• An API key is a fixed string tied to an account. Simple, and weak the moment it leaks.
• OAuth 2.0 hands out short-lived tokens instead of passwords, through a delegated authorization framework.
• A JSON Web Token is signed and self-contained, letting a server verify identity without a database lookup.
• Rate limiting caps how many requests one client can fire, blunting abuse and brute-force attempts.

GitHub requires OAuth authorization or a personal access token before returning any data from a private repository, a fairly standard pattern across major platforms.

Most breaches don’t come from cracking encryption. They come from a leaked API key sitting in a public code repository or a mobile app binary.

API Documentation Standards

Documentation earns its keep when a developer can tell what an endpoint does before writing a line of code against it.

The OpenAPI Specification is the industry standard format for describing REST APIs, covering endpoints, parameters, and expected responses in a machine-readable file.

Swagger is the toolset built around that standard, generating interactive documentation and client code straight from the specification file.

JSON Schema, a vocabulary for validating the shape of JSON data, remains developers’ top documentation format by a wide margin, according to Postman’s 2023 State of the API Report, with Swagger and OpenAPI 3.x close behind and nearly tied with each other.

Twilio publishes a full OpenAPI specification file for its entire API catalog on GitHub, letting developers auto-generate client libraries in whatever language they use.

Documentation worth reading covers all of this:

• Every endpoint and the HTTP method it accepts
• Required and optional parameters, with data types
• A sample request and a sample response
• Authentication requirements and error codes

Leave any of it out and integration support requests climb fast, since a developer with no example request is guessing.

API Versioning

Versioning is how a provider changes an API without breaking every application already built on top of it.

A peer-reviewed analysis of 317 Java libraries and 9,000 releases found that the median library broke backward compatibility in 14.78% of its API changes (Xavier et al., IEEE SANER), which is exactly the risk versioning exists to contain.

• URL-based versioning puts the number in the path itself, /v1/users and then /v2/users
• Header-based versioning moves it into a custom request header, keeping the URL clean
• Semantic versioning uses major.minor.patch numbering to signal how big a change is before anyone opens the changelog

A deprecation notice gives developers a warning window before an old version shuts down. A sunset timeline sets the date it actually stops responding.

X, formerly Twitter, forced a hard cutover from its v1.1 API to v2, and a large share of third-party apps that hadn’t migrated in time simply stopped working.

REST vs SOAP vs GraphQL: Choosing an Architecture

How predictable the data shape is. How much control the client needs over the response. What the team already knows how to build. That last one carries more weight in practice than most architecture write-ups admit.

A small team shipping a public API with no dedicated platform staff should take REST. Tooling and the hiring pool make that call for you.

GraphQL starts earning its added complexity once several client types pull different data shapes from the same backend.

In a regulated industry with strict contracts and audit requirements, SOAP still holds its ground, since the cost of migration rarely justifies dropping it.

Shopify made GraphQL the primary interface for its Admin API in 2024, marking the REST Admin API as legacy and citing fewer round trips for apps pulling multiple resource types into one screen.

Real-World API Examples

Abstract descriptions only go so far. Numbers out of production systems clear up most of what’s left.

• Stripe processed $1.4 trillion in payment volume through its API in 2024, up 38% year-over-year (Stripe, 2024)
• The average organization integrates 131 third-party APIs into its own systems (Traceable, 2025 State of API Security Report)
• GitHub’s REST API caps authenticated traffic at 5,000 requests per hour, a limit set directly in its own documentation

Slack’s API powers its entire app directory, letting outside developers build bots and integrations that post messages, react to events, and pull channel data.

Amazon Web Services exposes nearly every one of its cloud products, from storage to compute, through a documented API rather than a console interface alone.

When an API Does Not Apply

Sometimes an API is the wrong tool, and reaching for one anyway adds complexity nobody needed.

A script that reads a local file once doesn’t need an HTTP layer between two things running on the same machine.

Ultra-low-latency trading and control systems can’t absorb the extra hops. Serialization, a network round trip, deserialization, all of it costs microseconds that matter more than convenience in those environments.

Offline-first apps are another case. Something that has to keep working without a signal can’t depend on a live API call for every action.

And when two pieces of code live in the same process and the same codebase, a direct function call is faster and simpler than wrapping the same logic behind an endpoint.

None of this makes APIs a bad choice generally. It means the decision to add one should match the actual constraint, not a default habit.

How to Test an API

Testing confirms an API does what the documentation says before another team builds on top of it.

Katalon’s 2025 State of Software Quality report, based on a survey of 1,400 QA professionals, found 82% of testers still run manual tests daily, even as automated coverage grows elsewhere in the pipeline.

1. Read the documentation and note the required authentication method
2. Get valid credentials, whether that’s an API key, OAuth token, or test account
3. Send a basic request to a simple endpoint and confirm a 200 response comes back
4. Check the response payload matches the documented structure and data types
5. Test error handling by sending a deliberately bad request and confirming the status code makes sense

Most failures show up in steps three and four. A wrong header format or a missing authentication token causes more false alarms than the API actually being broken.

Reviewing a large batch of results outside the API client often means turning the raw JSON output into a spreadsheet-friendly format first.

Tools for API Testing

Postman is the most widely used API client, putting request building, automated test scripts, and mock servers in one tool. Insomnia is the lighter open-source alternative, covering REST, GraphQL, and gRPC in a cleaner interface. For scripting calls straight into a CI/CD pipeline or a shell script, curl still wins, no GUI involved.

PayPal publishes official Postman collections for several of its APIs, letting developers send working requests without building them from scratch.

FAQ on What Is An Api

Is an API Free to Use?

Depends entirely on the access type.

Public APIs usually run a free tier with usage caps before paid plans kick in. Private and partner APIs come out of internal budgets or negotiated contracts, so there’s no published pricing to look up.

What Is an API Gateway and When Do You Need One?

Sitting in front of multiple backend services, a gateway routes requests, enforces rate limiting, and handles authentication in one place.

Teams adopt one once they run several APIs together, since managing security and traffic per service individually stops scaling.

What Commonly Goes Wrong During API Integration?

Most integration failures trace back to authentication rather than the API itself. Expired tokens, wrong scopes, a missing header.

Version mismatches and undocumented rate limits cause the rest, especially when a client keeps calling an endpoint that was quietly deprecated.

Who Invented the API?

Nobody holds a patent on it.

British computer scientists Maurice Wilkes and David Wheeler documented the first API specification in 1951 for the EDSAC computer, and the exact phrase reached print in 1968, in a computer graphics paper presented at the AFIPS Fall Joint Computer Conference.

What Does an API Cost to Maintain After Launch?

More than it costs to build. Authentication upkeep, version management, and traffic monitoring together consume more engineering time after launch than writing the original endpoints ever required.

Postman’s 2019 State of the API Report found developers spend just 26% of their time actually building APIs, while debugging and manual testing alone consume another 22%.

The work falls in a fairly predictable order once an API ships. Authentication and token rotation come first, then version deprecation and breaking-change reviews, then traffic monitoring and rate-limit tuning.

Skipping that rotation step to ship faster trades short-term speed for a security incident further down the line.

Once authentication and endpoints are stable, the next step is learning how JavaScript calls these same endpoints from inside a browser or app.