Testing your own API
When your product is the API
Throughout this course, you've been on the consuming side: your app calls Twilio, Stripe, or Google Maps. But sometimes, your company is on the other side. Your product exposes an API that other developers use.
Maybe you work at a fintech and partners integrate your payment API. Maybe your platform has a public API that lets customers automate workflows. Maybe your product connects to other tools through an API.
In all these cases, the developers using your API are your users. And as a PM, you should be able to test what they experience.
Why PMs should test their own API
You wouldn't ship a new feature without clicking through it yourself. The same applies to your API. Testing it helps you:
- Catch issues before your users do. If a response is missing a field or an error message is confusing, you'll spot it.
- Understand what developers go through. If it takes you 20 minutes to figure out how to authenticate, imagine a developer evaluating your API against a competitor's.
- Write better specs. When you've actually sent a request and read the response, you know exactly what the API does. No guessing.
You don't need to test every edge case. Your QA and engineering team handle that. But sending a few requests to your own API and checking the responses? That's something any PM can (and should) do.
Postman: your testing tool
Postman is a free tool that lets you send API requests without writing code. You pick a method (GET, POST, PUT, DELETE), type a URL, add headers, write a body, and hit Send. It shows you the response in a clean, readable format.
Think of it as a browser for APIs. A browser only sends GET requests (when you type a URL and press Enter). Postman lets you send any kind of request.
Here's what testing a simple endpoint looks like in practice. Say your product has a public API and you want to test the "list all orders" endpoint:
You type this into Postman, hit Send, and get back the JSON response. You can immediately check: are the fields named clearly? Is the data correct? Does the pagination work? Is the error helpful if you remove the API key?
What to look for when you test
You're not debugging code. You're checking the experience. Here's what to pay attention to:
Do the responses make sense?
Send a request and read the JSON that comes back. Are the field names clear? If a developer sees "st": 1 in the response, they have no idea what that means. "status": "active" is obvious. Field naming is a product decision.
Are the error messages helpful?
Try sending a bad request on purpose. Remove the API key. Use a wrong endpoint. Send an invalid body. What comes back?
| What you send | Bad error | Good error |
|---|---|---|
| Missing API key | 401 Unauthorized | 401: Missing API key. Include it in the Authorization header as 'Bearer YOUR_KEY'. |
| Invalid phone number | 400 Bad Request | 400: Invalid 'phone' format. Expected E.164 format (e.g. +33612345678). |
| Non-existent resource | 404 Not Found | 404: No order found with ID 'ord_999'. Check the ID and try again. |
The difference is huge. A bad error makes developers open a support ticket. A good error tells them exactly what to fix. As a PM, you can flag this and push for better messages.
Does the documentation match reality?
Open your API docs side by side with Postman. Does the endpoint return exactly what the docs say? Are there fields in the response that aren't documented? Are there documented fields that don't show up? Mismatches between docs and reality are one of the top frustrations for developers using an API.
Is the sandbox working?
If your API has a test mode or sandbox, try it. Can a new developer sign up, get a test API key, and make their first call in under 5 minutes? If not, that's friction you should know about.
The DX checklist
When your product exposes a public API, developer experience is part of your product experience. Here's what good DX looks like:
| Area | What to check | Why it matters |
|---|---|---|
| Onboarding | Can a developer go from signup to first successful API call in under 5 minutes? | First impressions. If it's hard to start, developers try the competitor. |
| Documentation | Are there clear examples for every endpoint? Is there a quickstart guide? | Developers don't read docs top to bottom. They scan for examples and copy-paste. |
| Error messages | Do errors explain what went wrong and how to fix it? | Bad errors = support tickets. Good errors = self-service. |
| Sandbox | Is there a test mode with fake data and no real consequences? | Developers want to experiment before committing. No sandbox = no experimentation. |
| Consistency | Are naming conventions, pagination, and auth patterns the same across all endpoints? | If /orders uses 'limit' and /users uses 'count' for the same thing, developers get confused. |
| Changelog | Are breaking changes announced in advance? Is there a versioning strategy? | Developers build on top of your API. Breaking their integration without warning breaks their trust. |
You don't have to audit every line of documentation. But running through this checklist once in a while gives you a realistic view of what your API users experience.
Key takeaways
- When your product exposes a public API, the developers using it are your users. Their experience matters just as much as your end users' experience.
- Postman lets you test API requests without writing code. It's the easiest way to see what your API actually does.
- Focus on what you can evaluate as a PM: response clarity, error messages, documentation accuracy, and onboarding friction.
- Good developer experience (DX) isn't a nice-to-have. It's what determines whether developers choose your API or a competitor's.