Skip to content
simplytools.us
Technology · How it works

What is an API?

A plain-English guide to endpoints, requests, responses, API keys and rate limits — using the restaurant waiter analogy and a real weather example.

simplytools.us editorialUpdated 30 Oct 20263 min read

An API — application programming interface — is a set of rules that lets one piece of software ask another piece of software to do something. It is a contract, not a website.

The common analogy is a restaurant. You do not walk into the kitchen and operate the stove. You tell the waiter what you want from the menu. The waiter carries the order to the kitchen and brings back the result. The API is the menu plus the waiter: a defined way to ask, and a defined shape for the answer.

A concrete example

Suppose a weather service offers an API. Its documentation might say:

  • Send a request to https://api.example.com/v1/weather.
  • Include a city and an API key.
  • The response will be JSON containing temperature, conditions and a timestamp.

A request might look like:

GET https://api.example.com/v1/weather?city=Chicago
Authorization: Bearer YOUR_API_KEY

A response might look like:

{
  "city": "Chicago",
  "temperature_c": 18,
  "conditions": "cloudy",
  "observed_at": "2026-10-30T14:00:00Z"
}

The app does not need to know how the weather service stores data or which satellites it uses. It only needs to follow the contract.

The pieces you will see

  • Endpoint: a URL that represents a resource or action, such as /v1/weather.
  • Method: the verb, such as GET to read, POST to create, PUT or PATCH to update, and DELETE to remove.
  • Headers: metadata such as authentication, content type and language.
  • Parameters: values in the URL or request body, such as a city or date.
  • Response status: a number such as 200 for success, 404 for not found or 429 for too many requests.
  • Body: the data returned, often JSON.

Authentication and API keys

Many APIs require a key or token so the provider can identify the caller, apply limits and bill for usage.

An API key is a secret. It should not be pasted into client-side JavaScript, committed to a public repository or included in a screenshot. If a key is exposed, rotate it. For user-facing apps, keep the key on a server or use a short-lived token flow.

Authentication answers “who is calling?” Authorization answers “what are they allowed to do?” A valid key does not necessarily grant access to every resource.

Rate limits and errors

APIs usually enforce rate limits to protect their systems. A response might include headers such as:

  • X-RateLimit-Limit
  • X-RateLimit-Remaining
  • X-RateLimit-Reset

If you exceed the limit, the API may return 429 Too Many Requests. Good clients back off and retry later instead of hammering the endpoint.

Errors are part of the contract. A robust integration handles:

  • network timeouts;
  • 4xx errors caused by bad input or missing permission;
  • 5xx errors caused by the provider;
  • malformed or unexpected response data;
  • partial failures when several calls are needed.

REST, GraphQL and webhooks

REST is a common style built around resources and HTTP methods. It is simple and widely supported.

GraphQL lets the client ask for specific fields in a single query. It can reduce over-fetching, but it adds its own complexity and caching considerations.

Webhooks reverse the direction. Instead of your app repeatedly asking “has anything changed?”, the provider sends an HTTP request to your endpoint when an event happens. You then verify the signature and process the event.

APIs are not only for developers

Every time an app shows a map, processes a payment, sends an email or logs in with Google, an API is probably involved. Internal APIs connect a company's own services. Public APIs let outside developers build on a platform.

What to check before using one

  • Read the authentication and rate-limit rules.
  • Check the uptime and status history.
  • Understand the pricing, including overage charges.
  • Look at the data retention and privacy terms.
  • Test error responses, not just the happy path.
  • Plan for version changes and deprecations.
  • Never trust input from an API without validation.

An API is a convenience and a dependency. The contract makes integration possible, but it also means the provider can change the terms, the limits or the service. Good systems isolate that dependency so it can be replaced.

For the infrastructure behind these calls, read what is cloud computing?.

Editorial note: simplytools.us explains general concepts, not individual circumstances. This article is information, not financial, medical or legal advice. Verify important details with a qualified professional or official source.