What Is an API? Meaning, Examples and How APIs Work

If you're building a product, you'll hear the word "API" in almost every conversation with a developer. "We'll use the Stripe API for payments." "The map comes from the Google Maps API." "We can add AI with the OpenAI API." It sounds technical, but the idea is simple, and understanding it helps you make better decisions about cost, timelines and which tools to build on.

Quick answer: An API (Application Programming Interface) is a set of rules that lets one program ask another program for data or an action and get a structured answer back. On the web, your app sends a request to a URL called an endpoint, usually with a key that proves who you are, and the other service replies with data, usually in JSON, plus a status code that says whether it worked.

API full form and meaning

The full form of API is Application Programming Interface. Each word tells you something:

• Application: any piece of software, such as a banking app, a website's backend or an AI model.
• Programming: it's meant to be used by code, not clicked by people.
• Interface: a defined meeting point with fixed rules, like a power socket that any matching plug can use.

Put together, an API is the published "socket" one program offers so other programs can plug in and use its data or features without seeing how it works inside.

What is an API in simple terms?

API stands for Application Programming Interface. It's the agreed way for two pieces of software to talk: what you can ask for, how to ask, and what the answer will look like.

Think of a restaurant. You don't walk into the kitchen and cook. You read the menu, tell the waiter what you want, the waiter takes the order to the kitchen, and your food comes back. In this picture:

• The menu is the API documentation: the list of things you're allowed to order.
• The waiter is the API: it carries your request in and the result out.
• The kitchen is the other company's system, which you never see.
• Your order slip is the request, and the plate is the response.

The kitchen can change its ovens or hire new chefs, and as long as the menu stays the same, your order still works. That's the real value of an API: it hides the messy internals behind a stable set of rules.

The important part for founders: an API lets your product use features someone else has already built, tested and scaled, so your team doesn't have to build them from scratch.

How do APIs work?

Most APIs on the web follow the same basic pattern:

1. Your app sends a request. It goes to a specific web address (called an endpoint, which is just a URL) and says what it wants, such as "create a payment for ₹500."
2. The request proves who you are. Most APIs need a secret key or token, so the provider knows which account to bill and what you're allowed to do.
3. The provider does the work. It charges the card, looks up the address or generates the text.
4. Your app gets a response. The answer usually comes back as JSON, a lightweight text format that code can read easily, along with a status code that says whether it worked.

That whole round trip often takes well under a second, which is why users never notice it happening.

The parts of an API request

Every web API call is an HTTP request, the same kind your browser makes when it loads a page. It has a few parts:

• Endpoint: the URL you send the request to, for example https://api.github.com/users/octocat. The server behind it has an address of its own, which is what an IP address is.
• Method: the verb that says what you want to do (see the list below).
• Headers: extra labels on the request, such as your API key (Authorization) and the format you're sending (Content-Type: application/json).
• Body: the data you're sending, used when you create or update something. A simple read request has no body.

And the response comes back with:

• Status code: a three-digit number that says what happened.
• Headers: details such as the content type and, on many APIs, how many requests you have left.
• Body: the actual data, usually JSON.

HTTP methods

REST-style APIs reuse the standard HTTP methods:

• GET to read data (fetch a customer's details)
• POST to create something (start a new payment)
• PUT or PATCH to update something
• DELETE to remove something

MDN's guide to HTTP request methods is a reliable reference if you want the technical detail.

Status codes you'll see most

Code	Meaning	What it usually tells you
200 OK	Success	The request worked and the data is in the body
201 Created	Created	A POST made a new record
400 Bad Request	Bad input	Something in your request is missing or malformed
401 Unauthorized	Not signed in	The API key is missing or wrong
403 Forbidden	Not allowed	The key is valid but lacks permission
404 Not Found	Wrong address	The endpoint or record doesn't exist
429 Too Many Requests	Rate limited	You've hit the usage limit; slow down and retry later
500 Internal Server Error	Provider problem	Something broke on their side

The rule of thumb: 2xx means success, 4xx means a problem with your request, and 5xx means a problem with the server. The full list is in MDN's HTTP status code reference.

A real API example you can try

You don't need an account to see an API in action. GitHub's public REST API lets you read public profile data without a key. Open a terminal (Terminal on Mac or Linux, or Command Prompt on Windows 10 and 11, which include curl; in PowerShell, type curl.exe) and run:

curl https://api.github.com/users/octocat

That's a GET request to an endpoint. GitHub replies with status 200 and a JSON body that starts like this (shortened):

{
  "login": "octocat",
  "id": 583231,
  "name": "The Octocat",
  "html_url": "https://github.com/octocat",
  "public_repos": 8,
  "created_at": "2011-01-25T18:44:36Z"
}

Compare that with opening github.com/octocat in a browser. Same information, but the website wraps it in a page designed for people, while the API returns raw data a program can use directly, for example to show a developer's repo count on your own site.

If you look at the response headers (add -i to the command), you'll also see x-ratelimit-limit: 60. GitHub's documentation says unauthenticated requests are limited to 60 per hour; sending a token raises that limit. That's a small, real example of why API keys matter. See the GitHub REST API docs for more.

How to see real API calls in your browser (no coding)

Most websites and web apps call APIs constantly in the background. You can watch it happen in Chrome, Edge or any Chromium browser using the built-in DevTools, which Google documents here:

1. Open a web app you use, such as a weather site, an online store or your email in the browser.
2. Open DevTools by pressing F12, or Control+Shift+J on Windows and Linux (Command+Option+J on Mac), which opens the Console.
3. Click the Network tab. It only records activity while DevTools is open, so it may start empty.
4. Reload the page or click something in the app, such as a search or a filter.
5. Click the Fetch/XHR filter. This hides images, styles and scripts so you mostly see data requests, which are the API calls.
6. Click any request. The Headers tab shows the endpoint URL, method and status code, and the Preview or Response tab shows the data that came back, often JSON.

That's the same request, response and status code pattern described above, happening live. Just look, don't copy: request headers can include your own login cookies or tokens, so never paste them anywhere public.

Types of APIs

By how they're built

• REST: the most common style for web APIs. Each "thing" (a user, an order) has its own URL, and you act on it with HTTP methods. Responses are usually JSON. Stripe, GitHub and most SaaS tools offer REST APIs.
• GraphQL: a query language where you send one request to a single endpoint and say exactly which fields you want back. It avoids fetching too much or making many round trips. GitHub and Shopify offer GraphQL APIs alongside or instead of REST. See graphql.org.
• SOAP: an older, stricter protocol that uses XML messages and formal contracts. You'll still meet it in banking, insurance and government systems.
• WebSocket: keeps a connection open so the server can push updates instantly, which suits chat, live dashboards and multiplayer features. See MDN's WebSockets API guide.
• gRPC: a fast framework from Google that uses HTTP/2 and compact binary messages (Protocol Buffers). It's mostly used between internal services rather than for public APIs. See the gRPC introduction.

Which type of API fits which job?

If you're not sure, start with REST. It's what most public APIs offer, and almost every tutorial, SDK and no-code tool supports it.

By who can use them

• Public (open) APIs: available to any developer who signs up, sometimes free and often with paid tiers. Examples: OpenAI, Google Maps, Stripe.
• Partner APIs: shared only with approved business partners, often under a contract, such as a logistics firm giving a big retailer access to shipment tracking.
• Private (internal) APIs: used only inside one company, for example between a mobile app and its own backend. Most APIs in the world are this kind; you just never see them.

API vs website vs SDK vs webhook

These terms get mixed up a lot. Here's the difference:

Term	Built for	How it works	Example
Website	People	Shows pages with buttons, text and images in a browser	The Stripe dashboard
API	Software	Returns raw data when your code sends a request	Your app calling Stripe to create a payment
SDK	Developers	A ready-made code library that calls the API for you in a specific language	Stripe's Node.js or Python library
Webhook	Software	The provider calls your URL when something happens, instead of you asking	Stripe telling your server "payment succeeded"

A simple way to remember it: with an API you ask, and with a webhook you're told. An SDK is just a convenient wrapper around the API, so your developer writes less code.

Real API examples founders use every day

Stripe: taking payments

Building your own payment system would mean handling card security rules, banks, fraud checks and refunds. With Stripe's API, your app sends a request to create a payment, and Stripe handles the rest. Stripe also gives you separate test keys, so your developer can try everything with test card numbers before real money moves.

Google Maps: location and directions

Delivery apps, property listings and store finders often show a map, turn an address into coordinates, or estimate travel time. Instead of collecting map data of the whole world, they call the Google Maps Platform APIs. Your app sends an address or location, and Google sends back map tiles, coordinates or a route.

"Sign in with Google" and other logins

When an app lets you sign in with Google or Apple, it uses their authentication APIs. The app never sees your password; it receives a confirmation and basic profile details you agreed to share.

Weather, shipping and messaging

Weather widgets, courier tracking pages and the OTP text you get when logging in usually come from third-party APIs too. One app can easily depend on five or ten of them, and each connection is something to check after launch, which is part of website maintenance cost.

Automation tools

Workflow tools like Zapier, Make and n8n are essentially friendly layers on top of thousands of APIs. Our n8n vs Zapier comparison shows how two popular platforms use them.

What's in API documentation (the API details you need)

Before anyone writes code, the API's documentation is where the important details live. Good docs answer these questions, and if you're comparing providers, check each one:

1. Base URL and endpoints: the addresses you call, such as /users/{id} or /payments.
2. Authentication: whether you need an API key, an OAuth token or both, and which header to send it in.
3. Parameters and request body: which fields are required, which are optional, and the allowed values.
4. Example requests and responses: ready-to-run samples, often in curl, JavaScript and Python.
5. Error codes: what each status code and error message means for that API.
6. Rate limits and quotas: how many requests you can make per minute, hour or day, and how the API tells you when you're close.
7. Pricing: cost per call, per transaction or per token, plus any free tier.
8. Versioning and changelog: how the provider announces changes and retires old versions.

Many providers also publish an OpenAPI file. The OpenAPI Specification is an open standard for describing an API in a JSON or YAML document, so tools can generate documentation, test clients and code from it automatically. You'll often hear it called by its older name, Swagger.

AI APIs: OpenAI, Anthropic and Google Gemini

I use Grok, ChatGPT and Claude every day in my work, and most of the AI features you see inside other products run on APIs like these. The pattern is the same as any other API: your app sends a POST request with a prompt, and the model sends generated text back.

• OpenAI API: the models behind ChatGPT.
• Anthropic API: the Claude models.
• Gemini API: Google's Gemini models.

xAI offers a similar API for Grok. That's how a support tool can draft replies or a writing app can suggest edits without training its own model.

Two things are different from most APIs. First, AI APIs usually charge per token (small chunks of text) for both what you send and what comes back, so long prompts and long answers cost more. You can estimate this with my free AI token calculator. Second, the subscription you pay for in the chat app (like ChatGPT Plus or Claude Pro) is usually billed separately from API usage. For Claude's plans and API prices, see my Claude pricing guide and Claude Code pricing, and for a cheaper API option compare DeepSeek vs ChatGPT. If you're still choosing a model, read ChatGPT vs Claude.

Some AI APIs let you start free. Google's Gemini API pricing page lists a free tier with usage limits, though not every model is included, and paid usage is billed per token. Google's own API key guidance also warns never to hardcode keys in web or mobile apps, because keys in client-side code can be extracted; use a backend instead.

API keys and authentication basics

Most APIs need to know who's calling. The common methods:

• API key: a long secret string you send in a header with each request. Simple and very common (OpenAI, Anthropic and Google AI Studio all use them).
• OAuth: used when your app acts on behalf of a user, like posting to their calendar. The user approves access, and your app gets a token instead of their password.
• Bearer tokens: a token sent in the Authorization: Bearer ... header. Many API keys and OAuth tokens are sent this way.

Treat keys like passwords:

• Keep them on your server or in environment variables, never in public code, a website's front end or inside a mobile app where anyone can extract them. Frameworks with server code, such as Next.js, make this easier than a browser-only React app; see Next.js vs React.
• Use separate keys for testing and production, and give each the smallest permissions it needs.
• If a key leaks, revoke it and create a new one right away. Leaked AI keys can run up a bill quickly.
• Set usage limits or budget alerts where the provider offers them.
• If you connect an AI coding tool to a service through an MCP server, give it its own narrowly scoped key or a read-only mode. Our guide to MCP servers for web development explains how.

How to start using an API

1. Pick the API and read its docs. Good docs list the endpoints, required fields, example requests and error codes.
2. Check pricing and limits. Look at the free tier, cost per request or token, and rate limits before you commit.
3. Create an account and get a key. Use a test or sandbox key first if one is offered.
4. Make a first test call. Use curl, a tool like Postman, or the provider's own playground to see a real response.
5. Handle errors. Plan for 401s (bad key), 429s (rate limits) and 5xx errors (provider outages) with retries and clear messages to users.
6. Move to your app. Use the official SDK if there is one, keep keys server-side, and log usage so you can spot cost spikes.

If you don't code, no-code tools can connect many popular APIs for you. If you work with developers, AI coding assistants now make API integrations much faster; my comparison of Cursor vs Claude Code vs Codex covers the main options.

Common API errors and how to fix them

When an API call fails, the status code is your first clue. Here's what the common ones usually mean and what to try:

Two details are worth knowing. MDN explains that a 429 response may include a Retry-After header saying how long to wait. And GitHub's rate limit docs say that when you exceed its limit you get a 403 or 429 with x-ratelimit-remaining set to 0, and that authenticated requests get 5,000 per hour instead of 60. As for CORS, MDN's CORS guide explains that browsers block scripts from reading a response from another domain unless that server sends the right CORS headers, which is why the same request can work in curl but fail in your web page.

Common API mistakes to avoid

• Putting secret keys in front-end code. Anything in a website's JavaScript or a mobile app can be extracted. Keep secret keys on a server.
• Committing keys to GitHub. Use environment variables and a .env file that's excluded from version control.
• Ignoring rate limits. Retrying instantly in a loop after a 429 makes things worse and can get your access blocked.
• Not handling errors. Assume every call can fail, and show users a clear message instead of a blank screen.
• Skipping the pricing page. Per-call and per-token costs look tiny until real traffic arrives. Set budget alerts where the provider offers them.
• Building on an undocumented or "unofficial" API. It can change or disappear without notice. Stick to official, documented APIs for anything important.
• Never updating API versions. Read the changelog and plan upgrades before an old version is retired.

Why APIs matter for your business decisions

Understanding APIs helps you ask better questions before you build:

• Cost: many APIs charge per request, per transaction or per amount of text processed. Check the pricing page early, because usage costs grow with your users.
• Dependency: if a provider changes its prices, retires a version or goes down, your feature is affected. Ask your developer what the fallback plan is.
• Speed to market: using a proven API can save weeks of development compared with building the same feature yourself.
• Security and data: know what customer data you send to each provider and where it's stored, especially for AI APIs.

For a broader definition, IBM's overview of APIs and AWS's "What is an API?" are both good reads, and MDN's introduction to web APIs covers the APIs built into browsers.

FAQ