---
term: 'API (Application Programming Interface)'
seoTitle: 'What is an API? Application Programming Interface Explained'
headline: 'What is an API (Application Programming Interface)?'
slug: api
category: api-realtime
shortDefinition: 'An API is a set of rules that lets one application request data and functionality from another without knowing its internal code.'
relatedTerms:
  - rest-api
  - graphql-vs-rest
  - backend-sdk
  - auto-generated-database-apis
  - api-gateway-architecture
contrastsWith:
  - backend-sdk
faq:
  - question: 'What does API stand for?'
    answer: 'Application Programming Interface. "Application" is any software with a distinct function; "interface" is the contract between two of them — the defined set of requests one can make and the responses the other promises to return. The programming part is the point: it is an interface for software, where a UI is an interface for humans.'
  - question: 'What is an API in simple terms?'
    answer: 'A messenger with a menu. One program exposes a list of things it can do — fetch this data, perform that action — and other programs invoke them through defined requests, without ever seeing how the work happens inside. The classic illustration: a weather app does not measure the sky; it calls a weather service''s API.'
  - question: 'How does an API work?'
    answer: 'By request and response. The client sends a request to an endpoint — a URL naming the resource — with a method stating the intent, headers carrying metadata and credentials, and sometimes a body of data. The server validates it, does the work, and returns a status code plus a response body, usually JSON. Every integration you have ever used reduces to this loop.'
  - question: 'What is an example of an API?'
    answer: 'Sign-in with an identity provider, the payment step of a checkout, a map embedded in a delivery app, a weather widget — each is one application calling another''s API. Developer-facing examples are even plainer: a backend platform exposing your database as HTTP endpoints your mobile app queries.'
  - question: 'Is an API a database?'
    answer: 'No — it is the access layer in front of one. The API defines what may be asked and by whom; a database stores the data itself. An API often mediates between clients and a database precisely so that clients never touch the database directly — validation, permissions, and shaping happen at the interface.'
  - question: 'What is the difference between an API and an SDK?'
    answer: 'The API is the contract; an SDK is a toolkit for consuming it. An SDK wraps API calls in idiomatic language functions and adds session handling, retries, and types. You call an API over the wire; you import an SDK into your code — and under the hood, the SDK is making API calls.'
  - question: 'What are the types of APIs?'
    answer: 'By audience: public (open to any developer), partner (shared with contracted businesses), internal (private to one organization), and composite (bundling several calls). By style: REST, GraphQL, gRPC, SOAP, and WebSocket APIs. And beyond the web: library and operating-system APIs — interfaces existed long before HTTP carried them.'
  - question: 'What is an API endpoint?'
    answer: 'The specific URL where an API receives requests for one resource — /users/42 is the endpoint for user 42. Endpoint plus method defines an operation: GET /users/42 reads it, DELETE /users/42 removes it. Endpoints are the addressable surface of the whole interface.'
  - question: 'What is an API key?'
    answer: 'A generated string a client sends with each request so the provider can identify the caller, meter usage, and apply limits or revocation. It is identification more than authorization — production APIs layer real authentication, such as OAuth-issued tokens, on top for per-user permissions.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'API — MDN Web Docs glossary'
    url: 'https://developer.mozilla.org/en-US/docs/Glossary/API'
  - name: 'OpenAPI Specification'
    url: 'https://spec.openapis.org/oas/latest.html'
  - name: 'RFC 9110 — HTTP Semantics'
    url: 'https://www.rfc-editor.org/rfc/rfc9110'
  - name: 'RFC 6749 — OAuth 2.0 Authorization Framework'
    url: 'https://www.rfc-editor.org/rfc/rfc6749'
  - name: 'API — Wikipedia'
    url: 'https://en.wikipedia.org/wiki/API'
cta:
  title: 'Your backend, already an API'
  text: 'Define a data model on Back4app and the platform generates the REST and GraphQL APIs for it — endpoints, auth, and permissions included — with SDKs that speak them idiomatically from every major platform.'
  linkText: 'Start building free'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-07-24'
translationKey: api
---

**An API is a set of rules that lets one application request data and functionality from another without knowing its internal code.** The famous restaurant analogy — you order from a menu, the kitchen stays invisible — earns its one sentence and no more, because the real thing is more instructive than the metaphor: an API is a *contract*, and contracts are precise.

## Key takeaways

| Question | Answer |
| --- | --- |
| The definition | A defined request/response contract between two programs |
| The loop | Endpoint + method + headers + body → status code + response |
| By audience | Public · partner · internal · composite |
| By style | REST · GraphQL · gRPC · SOAP · WebSocket |
| The modern contract | A machine-readable spec (OpenAPI) that generates docs, clients, and mocks |

## Anatomy of an HTTP API Request and Response

No ranking explainer shows one, so here is an entire API call — request and response, nothing hidden:

```text
POST /classes/Todo HTTP/1.1              ← method + endpoint
Host: api.example-backend.com
X-Api-Key: app-7f2c…                     ← identifies the calling app
Authorization: Bearer eyJhbGci…          ← authenticates the user
Content-Type: application/json

{ "title": "Ship the release", "done": false }

HTTP/1.1 201 Created                     ← status: it worked, resource created
Location: /classes/Todo/xKd91m
Content-Type: application/json

{ "objectId": "xKd91m", "createdAt": "2026-07-24T10:30:00Z" }
```

The same call through an SDK — which is nothing more than this HTTP, wrapped in your language's idiom:

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
// One API call: create a record via the auto-generated REST API
const todo = new Parse.Object('Todo');
todo.set('title', 'Ship the release');
todo.set('done', false);
await todo.save();
// Under the hood: POST /classes/Todo with a JSON body → 201 Created
console.log('Created with id', todo.id);
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
// One API call: create a record via the auto-generated REST API
final todo = ParseObject('Todo')
  ..set('title', 'Ship the release')
  ..set('done', false);
await todo.save();
// Under the hood: POST /classes/Todo with a JSON body → 201 Created
print('Created with id ${todo.objectId}');
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
// One API call: create a record via the auto-generated REST API
var todo = Todo()
todo.title = "Ship the release"
todo.done = false
todo.save { result in
    // Under the hood: POST /classes/Todo with a JSON body → 201 Created
    if case .success(let saved) = result { print("Created with id \(saved.id ?? "")") }
}
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
// One API call: create a record via the auto-generated REST API
val todo = ParseObject("Todo")
todo.put("title", "Ship the release")
todo.put("done", false)
todo.saveInBackground { e ->
    // Under the hood: POST /classes/Todo with a JSON body → 201 Created
    if (e == null) println("Created with id ${todo.objectId}")
}
```

## How an API call works

```mermaid
flowchart LR
  accTitle: The API request and response loop
  accDescr: A client application sends a request with method, endpoint, headers, and body to an API, which validates and authorizes it, invokes backend logic and data, and returns a status code with a response body to the client.
  C["Client app<br/>(web, mobile, another server)"] -->|"request:<br/>method + endpoint + headers + body"| A["API<br/>validate · authorize · route"]
  A --> B["Backend logic<br/>+ database"]
  B --> A
  A -->|"response:<br/>status code + JSON"| C
```

Three properties of this loop explain why APIs run the modern stack. **Abstraction:** the caller needs the contract, never the implementation — the provider can rewrite everything behind the interface without breaking a single client. **Boundary:** validation and [permissions](/glossary/data-layer-vs-application-layer-security/) live at the interface, which is why clients talk to APIs and never to [the database](/glossary/nosql-vs-sql/) directly — an API is not a database; it is the gatekeeper in front of one. **Composition:** because every capability is callable, applications assemble from services — auth here, payments there, maps from a third — and, increasingly, AI agents use the same substrate: tool calling is API calling with a model deciding the requests.

## The contract: what an API actually promises

The pages that call an API "a contract" rarely show one. Today the contract is a machine-readable document — the [OpenAPI Specification](https://spec.openapis.org/oas/latest.html) is the standard for HTTP APIs — listing every endpoint, parameter, schema, and status code. From that single file, tooling generates reference docs, client libraries, server stubs, mock servers, and contract tests.

The contract framing has teeth because of *versioning*. Adding a response field breaks nobody; renaming or removing one breaks every consumer silently — so mature APIs distinguish additive from breaking changes, version their surface (`/v1/`, or via headers), and publish deprecation windows. An API without a change policy is a contract without terms: technically a promise, practically a surprise.

## The types of APIs

Query-shaped, because "types of APIs" is its own search: two taxonomies, not one.

**By audience:**

| Type | Consumers | Typical concerns |
| --- | --- | --- |
| Public (open) | Any registered developer | Keys, quotas, docs quality, versioning discipline |
| Partner | Contracted businesses | Legal agreements, SLAs, tighter auth |
| Internal (private) | Your own teams and services | Microservice contracts, faster change cycles |
| Composite | Clients needing bundles | One call orchestrating several — fewer round trips |

**By style:** [REST](/glossary/rest-api/) (resources at URLs, HTTP methods), GraphQL (client-shaped queries at one endpoint), gRPC (binary, contract-first, service-to-service), SOAP (XML envelopes, enterprise/legacy standards), and WebSocket APIs ([bidirectional, persistent](/glossary/websockets-real-time-sync/)) — compared in the next table.

And one paragraph the web explainers skip: not every API is a web API. A language's standard library, POSIX system calls, and a browser's built-in `fetch` and geolocation interfaces are all APIs — contracts between programs — that never cross a network. The web variety merely put the contract behind a URL.

## REST vs. GraphQL vs. gRPC vs. SOAP vs. WebSocket

| Style | Wire format | Model | Strongest at | Watch out for |
| --- | --- | --- | --- | --- |
| REST | JSON over HTTP | Resources + methods | Public CRUD APIs, cacheability, ubiquity | Over/underfetching on fixed shapes |
| GraphQL | JSON over HTTP | Client-composed queries | Diverse clients, nested data | Caching complexity, resolver N+1 |
| gRPC | Protobuf over HTTP/2 | Typed procedure calls | Internal service-to-service speed | Browser friction, binary debugging |
| SOAP | XML envelopes | Operations + WS-* standards | Legacy enterprise, formal contracts | Verbosity, tooling weight |
| WebSocket | Frames over one socket | Bidirectional messages | Real-time push, presence | You define the protocol yourself |

## Common use cases

- **Mobile and web backends** — every screen's data arrives through an API; the frontend never touches the database.
- **Third-party integration** — payments, identity, messaging, maps: capabilities rented through contracts instead of rebuilt.
- **Microservice communication** — internal APIs as the seams that let services deploy and scale independently.
- **Automation and scripting** — anything with an API can be orchestrated: CI pipelines, infrastructure, content workflows.
- **AI agents and tool calling** — models act by invoking APIs; a well-documented contract is now machine-consumed twice, by SDKs and by agents.

## Which API style should you choose? A decision matrix

| Your situation | Reach for |
| --- | --- |
| Public-facing CRUD over resources | REST — the lingua franca, cache-friendly |
| Many client types, each needing different shapes | GraphQL selection sets |
| Internal high-throughput service mesh | gRPC contracts |
| Real-time, bidirectional, always-on | WebSocket (or a live-query layer above it) |
| Enterprise partner with WS-* requirements | SOAP — because the contract says so |
| One screen needing five services | A composite endpoint or backend-for-frontend |

## Limitations and trade-offs

- **A contract binds the provider too.** Every published field becomes something someone depends on; evolution happens through versioning discipline, not silent edits.
- **Network APIs inherit the network.** Latency, partial failure, and retries are part of every remote call's semantics — local function calls never needed timeout policies.
- **Abstraction hides cost.** One innocent-looking call can fan out into expensive work; consumers see the menu, not the kitchen's bill — which is what [rate limits](/glossary/api-rate-limiting-throttling/) and quotas are for.
- **Security surface scales with surface area.** Every endpoint is a door; keys identify but do not authorize, so real auth ([OAuth 2.0](https://www.rfc-editor.org/rfc/rfc6749)-style tokens, per-user permissions) and input validation are table stakes.
- **Fixed shapes misfit some consumers.** The overfetching/underfetching trade-offs of endpoint design are their own topic — see [the sibling entry](/glossary/overfetching-underfetching/).

## APIs on Back4app

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. The defining move is that the API is *generated, not built*: define a data model and the platform exposes it as [REST endpoints and a GraphQL schema](/glossary/auto-generated-database-apis/) immediately — the dissected call above is real Back4app wire format — with keys, user tokens, and class-level permissions enforcing the contract at the boundary. The [SDKs](/glossary/backend-sdk/) consume that API idiomatically from every major platform, and custom operations become Cloud Code functions: new endpoints in one file, same contract discipline, no server to run.