The Anatomy of an API Call: Requests, Responses, and More
I broke this down in the video above. Below is the written version, expanded into a fuller guide to the anatomy of an API call and how to test each part of it.
Most testers use APIs every day without ever stopping to take one apart. If you want to test APIs well, that is the gap to close. In the video I used a hotel booking API as a running example, with a base address of api.hotelplaza.com, and walked through the pieces that make up one call. This one is for testers who can fire off a request but want to understand what is actually inside it. Here I want to break down the six components of an API call, endpoints, HTTP methods, requests, responses, status codes, and authentication, and show what to test in each.
What one API call is actually made of
An API call is built from six parts: an endpoint, an HTTP method, a request, a response, a status code, and authentication.
Those six pieces show up in every call you will ever test, whether it is a hotel reservation system or a payment processor. The endpoint is the address. The method is the action. The request carries what you send. The response carries what comes back. The status code is the verdict. Authentication proves who is asking.
What I learned testing APIs is that most defects live at the seams between these parts, not inside any one of them. I cover the full anatomy in the video. Once you can name all six, you can write a test for each, and that is the whole job.
Endpoints, the address of the resource
An endpoint is the specific URL where an API resource lives, and its structure tells you exactly what you are reaching.
An endpoint has layers. There is a base URL that every call shares, like https://api.hotelplaza.com/v1. After that comes the resource path, which names what you are accessing: guests for all registered guests, rooms for all rooms, services for everything the hotel offers. Then comes the parameter path, which narrows things down.
The hotel example makes it concrete. A path like guests/{guestId} points at one specific guest. rooms/{roomId}/availability asks whether one room is open. guests/{guestId}/reservations pulls every booking tied to a guest. When I test endpoints, I check that the structure resolves correctly, that valid IDs return the right resource, and that bad or missing IDs fail in a clean and predictable way.
HTTP methods, the verb that says what you want
The HTTP method is the action you intend, GET to read, POST to create, PUT to fully update, PATCH to partially update, and DELETE to remove.
Each method has a clear job. GET retrieves data and changes nothing, like fetching all available rooms. POST sends data to create something new, like registering a new guest. PUT updates an existing resource and usually expects the entire updated entity, like a full guest profile after a reservation change. PATCH is the partial cousin of PUT, sending only the change, like updating just a checkout date. DELETE removes a resource, like canceling a booked service. I demonstrate each one against the hotel API in the video.
The PUT and PATCH distinction trips up a lot of teams, and it is worth testing carefully. With PUT you send the whole object, so a missing field can wipe out data. With PATCH you send only what changed. I test both paths deliberately, because a service that quietly treats a partial PUT as a full replace is a defect waiting to corrupt a record.
Requests and responses, the exchange
A request carries the method, headers, and sometimes a body, and the response comes back with headers, a status code, and a body.
On the request side, a GET for room 101 needs no body, because you are only reading. A POST to register a guest carries a body with the details, like first name, last name, email, and room number. A PUT to update guest 1234 sends the full set of fields. A PATCH to that same guest sends only the new email. A DELETE for a reservation needs no body at all.
The response is the server’s reply. A successful read returns the resource and an OK result. A successful create returns a created result with a confirmation. A successful delete returns no content. Then come the failures. A registration with a missing first name or email returns a bad request that names the invalid input. A GET for room 999 that does not exist returns not found. A registration that hits a downed database returns an internal server error. I found that testing only the happy path is the most common API testing mistake, so I write a case for each of those failure responses too.
Status codes, the server’s one-line verdict
Status codes are three-digit signals grouped into families: 100s informational, 200s success, 300s redirection, 400s client errors, and 500s server errors.
The families are easy to remember once you see them grouped. The 200 series means success, with 200 for a good request, 201 for a created resource, and 204 for success with no content to return. The 300 series handles redirection, like 301 moved permanently and 304 not modified. The 400 series points at the client: 400 for bad syntax, 401 for missing authentication, 403 for forbidden, 404 for not found, and 429 for too many requests. The 500 series is the server’s fault, with 500 for an internal error, 502 for a bad gateway, and 503 when the server is overloaded or under maintenance.
For a tester, the code is the assertion. It is not enough that the body looks right. I check that a create returns 201 and not a bare 200, that an unauthenticated call returns 401, and that a missing resource returns 404. The status code is the contract, and a wrong one is a bug even when the payload looks fine.
Authentication, proving who is calling
Authentication confirms the identity of whoever is making the call, through passwords, tokens, API keys, OAuth, multi-factor, or certificates.
Authentication is how the system verifies that an entity is who it claims to be, and it matters for security, personalization, and accountability. The common methods run from a username and password, to token-based authentication where a token rides along with each later request, to an API key sent in the request header. OAuth is the protocol behind logging into a new app with your Google or Facebook account, granting access without handing over a password. Multi-factor adds a second proof, and certificate-based authentication is common for server-to-server calls.
Each method gives you something specific to test. I check that a call with no credentials is rejected, that an expired or malformed token fails cleanly, that a wrong API key returns the right error, and that a valid login returns exactly the access it should and nothing more. Authentication is where a small gap becomes a serious breach, so it earns careful testing.
The takeaway
One API call is made of six parts, and good API testing means testing each one. The endpoint is the address you verify. The method is the action you confirm behaves correctly. The request and response are the exchange you check on both the happy path and every failure. The status code is the verdict you assert on. Authentication is the gate you probe. Take an API apart this way and you stop guessing about what to test, because every piece tells you what it needs.
If this helped, the full walkthrough is in my video on the anatomy of an API call. Here is my question for the comments: which part of an API call does your team most often forget to test? Subscribe if you want more grounded explanations of testing and quality.
