How an API Request Works: Endpoint, Method and Headers

by Souy Soeng /October 23, 2026

Diagram of an API request split into three labeled parts: endpoint, method and headers

An API request is a structured question your app sends to another service, and every one is built from three parts: an endpoint, a method and headers. The endpoint says where to ask, the method says what you want to do, and the headers carry extra details, such as who you are.

When a weather app shows today's forecast, it has quietly sent one of these requests and read the answer. This guide walks through that process in order, using a weather example. By the end you will be able to send a real request yourself, read the JSON that comes back, and work out what to change when something goes wrong.

In short

Every API request has three parts: the endpoint (where), the method (what) and the headers (details).
Start with a GET request, because it only reads data and changes nothing on the server.
Add query parameters, headers and an API key only when the API's documentation asks for them.
A successful request returns status 200 and the data you actually asked for.
Error codes point to the fix: 401 means check your key, 404 the URL, 405 the method.

Set your goal and gather the tools

Before typing anything, it helps to know exactly what you are aiming for. The goal here is small and concrete: send one real request to an API and understand every part of the reply. If you can do that once, you have the core skill in miniature, and every other API builds on the same pattern.

The list of things you need is short, and everything on it is free. A web browser lets you read API documentation. A request tool, either curl in your terminal or the Postman app, does the actual sending. The last item is curiosity, because experimenting with a real API teaches you faster than reading about one.

Keep the guiding question in mind as you go: where does a weather app actually get its data? Each step below answers part of that question, from choosing the address to checking the reply.

A web browser for reading the API's documentation
curl or Postman installed and ready to use
A clear goal: send one request and read its JSON reply

Pick an endpoint: where the request goes

The first decision is where to send your request. That place is the endpoint: one specific URL where an API offers one kind of data. A helpful picture is a building with many doors. Each endpoint is one door, and behind it sits a single kind of data, such as current weather or a list of users.

An endpoint is made of two pieces. The base URL is the API's home address, and it stays the same for every endpoint the API offers. The path comes after it, in this example /v1/weather, and it chooses which kind of data you get. Change the path and you walk through a different door of the same API.

Never guess an endpoint. The API's documentation lists every one exactly, usually with the base URL near the top of the page. Copy endpoints from there rather than typing them from memory, because a single wrong character sends your request to a door that does not exist.

Find the base URL near the top of the API documentation
Choose the path that matches the data you want
Copy the full endpoint instead of retyping it

# base URL: the API's address
https://api.example.com
# path: which data you want
/v1/weather
# together they make the endpoint

Choose a method: GET or POST

Once you know where to send the request, you need to say what you want to do there. That is the method's job. You can think of it as the verb in your sentence to the API. The same endpoint can behave differently depending on which method you use, and two methods cover most beginner needs.

GET reads data. You ask for the weather, users or posts, and nothing on the server changes. POST sends new data, such as creating a post or placing an order, and it usually carries that data in a request body. The difference matters: one only looks, the other makes something new.

Start with GET. Because it only reads, you cannot break anything by trying it, which is why the weather example in this guide uses it. Then check the documentation, which says which methods each endpoint accepts. If you use one it does not allow, the API will refuse the request.

Use GET to read data without changing anything
Use POST when you are sending new data
Confirm in the docs which method the endpoint expects

Add query parameters, headers and an API key

With a place and an action chosen, the next step is the details. Without them, the API may not know which city you mean, or whether you are allowed to ask at all. Add only the details your API actually requires; the documentation tells you which ones those are.

Query parameters narrow down what comes back. They appear in the URL after a question mark, written as name=value pairs, like city=Paris. Headers are labels attached to the request itself. They tell the API things such as which format you want returned, without changing the URL.

Many APIs also want an API key so they know who is asking. In the example below, curl calls the weather endpoint, city=Paris adds a query parameter, one header asks for JSON, and the last header carries the key. Treat that key like a password and keep it out of screenshots and public code.

Put filters like city=Paris after a ? in the URL
Add a header asking for JSON if the API supports it
Send your API key in the header the docs specify
Never paste a real key into public code or screenshots

# GET the weather endpoint
curl -G https://api.example.com/v1/weather \
  -d city=Paris \
  -H 'Accept: application/json' \
  -H 'Authorization: Bearer YOUR_KEY'

Send the request and watch the reply

Your request is now complete: an endpoint, a method and its details. Every API call is a short conversation. You speak first, the API checks what you sent, and then it answers. In our example, GET /v1/weather travels to the server along with the headers and API key, and the API replies with 200 OK plus JSON.

In curl, paste the command from the previous step into your terminal and press Enter. The reply prints straight back into the same window. In Postman, choose GET, paste the URL, add your headers in the Headers tab and click Send. The response appears in the lower panel.

curl: paste the command and press Enter
Postman: pick GET, paste the URL, add headers, click Send
Look for the reply in the terminal or Postman's lower panel

Read the JSON response

The reply arrives as JSON. It can look busy at first, but it is built from only a few pieces, and once you can spot them, any JSON response becomes readable no matter how long it is.

Keys and values come in pairs: a name in quotes, a colon, then the data. In the example, city is a key and Paris is its value. Objects use curly braces to group related pairs, and one object can sit inside another, like the sky details nested under now. Arrays use square brackets to hold an ordered list, here a list of days.

Read from the outside in. The response opens with a curly brace, works through its keys one by one, and closes with a matching brace. When you meet a nested object or an array, step inside it and read it the same way.

Keys are names in quotes; values follow the colon
Curly braces mark an object of related pairs
Square brackets mark an array, a list in order

{
  "city": "Paris",
  "now": { "sky": "cloudy" },
  "days": ["Mon", "Tue", "Wed"]
}

Check for status 200 and the right data

Getting a reply is not the same as getting the right reply. A response can arrive and still be wrong, so check two things before calling it a success: the status code, and whether the data matches what you asked for.

Status 200 means the API understood your request and answered it. Postman shows the status above the response; in curl, add -i to your command to see it. Then open the body and compare. If you asked for Paris, you should see city: Paris. If the data looks wrong or empty, recheck your query parameters, since they decide what comes back.

Status reads 200 OK
Body is a JSON object, not an error message
Returned values match what you requested

Fix common API errors: 401, 404 and 405

Sometimes the status is not 200, and that is completely normal. The useful part is that each common error points back to one of the parts you built, so you always know where to look.

A 401 means unauthorized: your API key is missing or wrong, so check the key and the header carrying it. A 404 means not found: there is no such endpoint, so check the URL for typos. A 405 means the method is not allowed, so switch to the method the documentation lists for that endpoint.

Also read the response body. Many APIs return a short JSON explanation alongside the error code, and it often names the exact problem. Reading it first can save a lot of guessing.

401 Unauthorized: check your API key header
404 Not Found: check the URL for typos
405 Method Not Allowed: use the method in the docs
Read the error body for a specific explanation

Repeat the same steps with any API

What felt new at the start is really a short routine you can repeat with almost any API. Pick an endpoint URL. Choose GET or POST. Add parameters, headers and an API key if you need them. Send the request and read the JSON. Check for status 200. If it fails, remember the shortcut: 401 means key, 404 means URL.

The best way to make this stick is to try it on a free API. Once you have sent a few GET requests comfortably, the natural next step is sending data with POST, which uses the same three parts plus a request body.

Key takeaways

Every API request comes down to where (endpoint), what (method) and details (headers).
Copy endpoints from the documentation instead of guessing them.
GET is the safest first request because it only reads data.
Keep your API key private, like a password.
Success means status 200 and data that matches your request.
Error codes tell you which part to fix: key, URL or method.

Frequently asked questions

What are the three parts of an API request?

The endpoint, the method and the headers. The endpoint is the URL that says where to ask, the method says what action you want, and the headers carry extra details such as the response format and your API key.

What is the difference between GET and POST?

GET reads data from the API and changes nothing on the server. POST sends new data, such as creating a post or an order, and usually carries that data in a request body.

Where do I put my API key in a request?

Many APIs expect it in a header, but the exact header name and format come from the API's documentation. Wherever it goes, treat it like a password and keep it out of screenshots and public code.

What does status 200 mean in an API response?

It means the API understood your request and answered it. You should still check that the returned data matches what you asked for, since a reply can arrive with the wrong or empty data.

Why am I getting a 401 or 404 error?

A 401 usually means your API key is missing or wrong, so check the key and its header. A 404 means the endpoint does not exist, which is often a typo in the URL.

Do I need Postman to send an API request?

No. curl, a free command-line tool, works just as well; you paste the command into a terminal and the reply prints back. Postman offers the same thing through a visual interface.

Watch the full video on YouTube →

Tag

Ad