APIs for Product Managers
HTTP Methods and Status Codes: The Vocabulary You Need
Every API action reduces to one of four verbs. Every result reduces to one of five number ranges. Learn both and you can follow almost any technical conversation about an API's behavior.
THE METHODS (VERBS)
Method | Plain English | Example |
|---|---|---|
GET | "Read this, change nothing" | Fetch a customer's profile |
POST | "Create something new" | Create a new order |
PUT / PATCH | "Update something that exists" (PUT replaces the whole thing, PATCH updates part of it) | Change a customer's shipping address |
DELETE | "Remove this" | Cancel a subscription |
The distinction that trips PMs up: GET requests should be "safe" — calling one twice should never change anything. If an engineer tells you a GET endpoint has a side effect (like incrementing a counter or sending an email), that's usually a design smell worth a question, not a fun fact to nod at.
THE STATUS CODES (RESULTS)
Range | Meaning | What it tells a PM |
|---|---|---|
2xx | Success | The request worked as intended |
3xx | Redirect | "Look elsewhere for this" — rarely a PM concern |
4xx | Client error | The caller did something wrong — bad input, no permission, resource doesn't exist. This is where your error-message quality lives, and error messages are a product surface, not an engineering afterthought. |
5xx | Server error | You broke — a bug, an outage, a dependency failure. This is an incident, not a support ticket. |
The 4xx range is chronically under-owned by product. A 404 Not Found with no explanation, versus a 404 with a body that says "No customer found with id 8842 — check that you're using the live key, not the test key", is the difference between a five-minute integration and a ticket in your support queue. This is exactly the kind of decision that's technically trivial and product-critical, and it's yours.
YOUR MOVE THIS WEEK
Pull up your product's error responses — ask an engineer to show you the actual body of three different 4xx errors your API returns today. Read them as if you were a developer who has never spoken to your team. If you'd be confused or annoyed, you've found a cheap, high-leverage fix.