What Is an API? Requests, JSON, API Keys and Integration

In everyday life

Open a weather app on your phone, and the forecast for where you are appears at once. But the company that made the app may not watch the sky itself. Often, it asks the server of a company that has weather data: "Please send the forecast for this place." A server is a computer that hands out data when asked.

The same thing happens in other places. A store's website may have a Google Maps map built into the page. A login screen may show a "Log in with Google" button. In each case, one program is asking a program run by another company to do a job.

For this to work, everyone has to ask in the same way. What can you ask for, how do you write the request, and what form does the answer take? An agreement that settles this in advance and is shared with others is called an API. It stands for application programming interface.

An API is an agreement about how to ask

An interface is the place where two things meet and connect. So an API is the agreement used where one program connects to another. The key point is who uses it. It is not made for people working a screen. It is made for programs.

The agreement mainly sets out the following.

• The names of jobs you can ask for (for example, "look up the forecast")
• The information to send with a request (for example, the place and the date)
• The form of the answer (for example, temperature as a number, in °C)
• The reply when something goes wrong (for example, "that place is unknown")

The asking side gets answers without knowing how the other side calculates the forecast. In turn, the answering side can rebuild its insides, as long as it keeps the agreement. The asking side can keep using it unchanged.

The agreement is usually written down as a document. This is called the specification, or the API documentation.

Web APIs: asking over the internet

Some APIs, like those for weather and maps, ask a server on the other side of the internet. These are called web APIs. Today, when people say "API," they often mean a web API.

Most web APIs use HTTP, the same rules a browser uses to open a web page. In HTTP, the asking side sends a request, and the server sends back a response. HTTP itself is also covered in "What Does HTTPS Mean?"

The difference from a web page is what comes back. A web page returns text and images for people to read. A web API returns data in a form that programs can read easily.

Let's look at a request and a response for a made-up weather API. The server name "api.example.com" is reserved for examples. It is not a real service.

"GET" on the first line of the request is the kind of request: "I want to get data." This kind is called the HTTP method. Next, "/forecast?city=tokyo" is what you are asking for. Here it says "the forecast, for Tokyo."

"Host" on the second line is the name of the server. How a name is turned into a machine's number is explained in "How Does DNS Work?" The third line is a key that shows who is asking (more on this later).

"200" on the first line of the response is a number that means "it worked." This three-digit number is called the HTTP status code. Each result has its own number. For example, 404 means the item was not found, and 429 means too many requests.

For designing web APIs, an idea called REST is widely used. Roy Fielding, who helped write the HTTP standards, named it in his PhD dissertation in 2000. A common form gives each kind of thing (such as forecasts or orders) its own address. HTTP methods then say whether to get it, delete it and so on. An API like this is called a REST API.

JSON: a data format programs read easily

The part of the response inside "{ }" is written in JSON (pronounced like the name "Jason"). "application/json" on the second line of the response marks the body as JSON. Each pair joins a name and a value with ":", and pairs are separated by ",". Names and text values go inside double quotes ("…"), while numbers are written as they are.

Here is the example response as a table.

Notice that "22" has no unit. Is it °C, or °F (Fahrenheit, used in the US)? That is written in the API's specification, not in the JSON. If you use an API without reading the specification, mix-ups like this happen.

The JSON format is defined in RFC 8259, a 2017 standard. It is based on how the programming language JavaScript writes data. Today, almost every programming language can read and write it.

API keys: showing who is asking

Many web APIs do not accept unlimited requests from just anyone. They issue each user or company a long string of characters that cannot be guessed. This is called an API key. The asking side sends this key with every request.

When the server receives a key, it can tell which user sent the request. It then decides whether that user may use the feature. It also counts the calls to work out the fee. For example, Apple's weather API is called WeatherKit. As of October 2026, up to 500,000 calls a month are included in the cost of its developer membership.

Why keys must stay secret, and how to protect them

That is why an API key is kept secret, just like a password. Send it only over encrypted HTTPS ("What Is Encryption?"). Take special care not to write a key directly into a program's files. If that program is made public, the key is made public to the world too.

Putting a key inside a phone app or a web page is also dangerous. Anyone who has a copy of the app or page can pull out its contents and inspect them. Keep secret keys only on your own server. That server then adds the key and sends the request on.

Leaks really do happen, and often. GitHub is the best-known service for storing and sharing program code. The security company GitGuardian published a report in March 2025. In 2024, about 23.8 million secrets, such as keys and passwords, were found on public GitHub.

Google gives advice like the following for handling API keys.

• Do not put keys in the code of apps or web pages. Do not put them where the code is stored either.
• Restrict each key to the websites and features that may use it.
• Delete keys you no longer use.
• Replace keys with new ones on a regular schedule.

Some keys, however, are designed to sit in a page where people can see them. For example, the key that puts a map on a store's website is visible to anyone who views the page. This is a different kind of key. It is protected by a restriction such as "accept requests only from this store's website." Check the issuer's documentation to find out whether a key may be visible.

Limits on the number of calls (rate limits)

Many web APIs cap how many requests you can make in a set time. This is called a rate limit. It stops a few users from taking all of a server's capacity and making everyone else wait. It also stops a faulty program from repeating requests and running up costs.

For example, GitHub's API, as of October 2026, allows 60 requests an hour without anything that shows who is asking. If the request shows who the user is, you can make up to 5,000 requests an hour.

Over the limit, many servers reply "429 Too Many Requests." This number was defined in RFC 6585, a 2012 standard. The reply may also say how many seconds to wait before asking again. A well-built app follows this and waits before it tries again.

Behind "Log in with Google"

When you "Log in with Google" on another site, you are not giving that site your Google password. The screen where you type the password belongs to Google. The site receives a proof issued by Google that says "this really is the person." It contains no password.

This method is based on rules called OAuth (pronounced "oh-auth"). OAuth lets you give another app permission to use something, up to a set limit, without handing over your password. The current version, OAuth 2.0, became a standard in 2012.

Permissions and proofs are passed around as data called tokens. A token is like a pass with an expiry date that works only for certain things. If one leaks, the damage is smaller and shorter than if a password leaked.

For logging in, a set of rules called OpenID Connect is used. It adds a way to say "who this person is" on top of OAuth 2.0. Google's login follows it too. The proof of who you are arrives in a token called an ID token.

APIs are not only for the web

The word API was in use long before web APIs spread. For example, when an app wants to save a file, it asks the OS. The OS (operating system) is the base software that manages a computer's or phone's parts and lends them to apps. The way to ask it is also an API, and each OS has its own ("What Is an Operating System?").

A program that bundles often-used features into ready-made parts is called a library. Drawing a graph or calculating dates are examples of such parts. A library also has an API: which part to call, and how. These calls happen inside the same device, so they do not go over the internet.

What "API integration" means at work

At companies, you often hear "let's integrate these two systems through an API." It means making separate systems exchange data automatically through APIs. Nobody has to export data from one screen and import it into the other by hand.

One example is accounting software that pulls in a bank account's deposits and withdrawals automatically. In Japan, amendments to the Banking Act and related laws set up a system for this kind of link. They passed in May 2017 and took effect in June 2018. Banks were required to make efforts to set up API connections with household-budget and accounting service companies.

Another use is passing an online shop's orders to a delivery company automatically. In each case, a service that an outside company provides in the cloud is connected to a company's own systems ("What Is Cloud Computing?").

What to check before connecting

• Which data flows, and in which direction (if it includes personal data, also the rules for handling it)
• Whose permissions the connection uses, and whether it allows only what is needed (the principle of least privilege)
• What happens if the other side's API goes down or its agreement changes
• The limit on the number of calls, and the fees
• Who keeps the API keys and tokens, and where

Common misconceptions

By the numbers

Standards stay in use for a long time. Rate limits and fees, though, often change for business reasons. When you use an API, check the provider's current documentation.

Learn more

• Terms for your next step: JWT (one format for tokens), cookie, WAF
• See the differences in a table: HTTP/1.1 vs HTTP/2 vs HTTP/3, IaaS vs PaaS vs SaaS, static vs dynamic linking (how libraries are attached)
• Test why long keys are hard to guess: the password brute-force time calculator
• Read the basics: "How Is Data Sent Over the Internet?" and "How Are Passwords Cracked?"