King K.D

The Anatomy of an API Request

Part 2 of the APIs for Non-Engineers Series

December 5, 2025 · 6 min read

Part 2 of the “APIs for Non-Engineers” Series

This article continues from the first piece in the series, "Understanding APIs and Their Role in Modern Products."

In that article, we explored what an API is at a high level and how APIs support the structure and behaviour of the digital products we use every day.

This second article goes one step further.

Here, we look closely at what actually makes up an API request: the parts, the purpose of each part, and how they work together to help two systems communicate clearly.

If you come across any terms that feel unfamiliar, the glossary here provides simple definitions you can refer to at any time as you read through this series.

What an API Request Really Is

When one application needs something from another system (such as information, an action, or a confirmation), it sends that request through an API.

A simple way to think about an API request is to imagine writing a short, structured message that follows a specific format:

  • who you are sending the message to

  • what you want to do

  • any information needed to complete the request

  • and any permissions that prove you’re allowed to ask

The format is consistent so that both sides understand each other clearly.

Even though the systems may be complex internally, the request itself follows a predictable pattern. That pattern is what we will break down here.

Endpoints: The Specific Place You’re Making Your Request To

An endpoint is the exact location inside an API where your request is meant to go.

Think of it as a precise address.

A complete endpoint address consists of two parts:

  • Base URL: The general location of the API server (like the building address)

  • Endpoint path: The specific resource or action you want (like the room number)

For example, if the base URL is "https://api.example.com", then a complete endpoint might look like:

  • https://api.example.com/customers

  • https://api.example.com/customers/123

  • https://api.example.com/transactions

  • https://api.example.com/payments/summary

When engineers talk about endpoints, they sometimes refer to just the path part (like /customers or /customers/123) because the base URL is already known. But the full address always includes both parts.

Each endpoint leads to a different “resource”: a piece of information or an action the system can perform.

If APIs were buildings, an endpoint would not be the whole building. It would be the specific office and room number you want to visit. This helps the system know exactly what you are asking for.

Methods: The Type of Action You Want to Perform

Every API request uses a method to tell the system what kind of action you want.

Without this instruction, the system would not know how to handle your request.

The common methods are:

GET: “Show me something.”

  • Used when you simply want to retrieve information.

POST: “Create something new.”

  • Used when you want to add new information.

PUT/PATCH: “Update something that already exists.”

  • Used when the information is already there but needs to be modified.

DELETE: “Remove something.”

  • Used when something should be removed from the system.

Even without writing any code, understanding these four meanings makes it easier to follow conversations involving API behaviour.

Headers: Extra Information the System Needs

Headers act like the small but important details that travel along with your request.

They are not visible to most users, but they are critical because they:

  • identify who is making the request

  • provide any necessary permissions

  • describe the type of data being sent

  • help the system interpret the request correctly

One of the most important headers is the Authorization header. It usually looks like this:

Authorization: Bearer <token>

This simply means, “Here is the key that shows I am allowed to make this request.”

Different companies handle authentication in different ways. While some use the Authorization header, others might use a simpler format like:

api-key: test_sk_my_key

The specific format depends on how each API provider chooses to structure their headers. What matters is that the key or token is included somewhere in the headers so the system knows you have permission to make the request.

Headers might sound technical, but the idea behind them is simple, which is, they provide the little details a system needs to trust and understand your request.

The Body of the Request: When You Need to Send Data

Some API requests require additional information to be sent along with the main message.

For example, if you want to create a new customer record, you have to include the details of that customer. This extra information is placed in the body of the request.

An example might look like:

{
  "name": "Ada Lovelace",
  "email": "ada@example.com"
}

This is just a structured format for listing information.

You don’t need to know how to write it, only that this is how information is sent from one system to another when needed. Not all requests need a body. Some only need an endpoint and a method.

But when information must be added or updated, the body contains the details required.

The Response: The System’s Reply

After your request is sent, the system you’re talking to sends a response back.

A response always contains two things:

1. A status code

This is a short number that tells you what happened. See the status code glossary entry for more details:

  • 200 → the request succeeded

  • 201 → a new item was created

  • 400 → something was wrong with the request

  • 401 → you don’t have permission

  • 404 → the requested item doesn’t exist

  • 500 → the system encountered an error

Status codes are simple but extremely helpful: they act as the first indicator of how the request went.

2. The response body

This contains the actual information returned by the system. This is the body of the response.

For example:

{
  "id": 123,
  "name": "Ada Lovelace",
  "email": "ada@example.com"
}

The response is the system’s way of answering your question or confirming your request.

Putting It All Together: A Simple Example

Let’s imagine the following request:

  • You want information about customer number 123

  • You have permission to see it

  • You are simply retrieving data, not updating anything

Here is how that request looks conceptually:

Request

Response

  • Status code: 200 OK

  • Body:

    {
  "id": 123,
  "name": "Ada Lovelace",
  "email": "ada@example.com"
}

This complete exchange (the request and the response) is what happens every time two systems communicate through an API.

Why Understanding Request Structure Matters

Knowing how an API request is put together helps non-engineers understand:

  • why certain errors appear

  • why some actions take longer

  • what engineers mean when they talk about “endpoints” or “methods”

  • how to read API examples in documentation

  • what parts of the request matter most for planning or troubleshooting

Even though APIs are technical tools, the concepts behind them are straightforward once broken down.

Next in the Series

In the next article, we will look at “Why APIs behave the way they do”: including errors, timeouts, delays, rate limits, and other behaviours that can seem confusing until you understand the underlying reasons.

Test Your Knowledge

Take a quiz to test your knowledge of endpoints, methods, headers, bodies, and responses by clicking this button: