The manual for an API: which endpoints exist, what to send, what comes back. PMs read these too.
Why it exists
An API is only usable if the people calling it know exactly what to send and what they will get back, and word of mouth does not scale across teams or companies. Guesswork leads to broken integrations. API documentation exists as the written contract and reference, so a developer can integrate correctly without reading the source or asking the author.
How it actually works
Before integrating any service, engineers read its docs to learn the endpoints, required fields, error codes, and limits. Good docs make integration fast; bad docs make it painful and slow.
As a PM, reading an API's docs tells you what is possible before committing to it: what data you can get, what actions you can trigger, what it costs.
A senior PM walks you through it
A junior PM, stuck
We have a call with a payment gateway vendor tomorrow and my lead wants to know before it whether their API can automate refunds, so we do not build a plan around something they cannot do. All I have is their public API docs. I do not want to walk in and take a salesperson's word for it either way.
You can settle this yourself tonight, and the docs are more honest than the sales call will be. A capability that exists has an endpoint documented for it, and a capability that is missing leaves a hole you can point at. This is the vendor's actual doc page, trimmed. Read it, then take the steps with me and you will find your answer in what is not there.
Gateway API docs, v1
POST /v1/charges
Required: amount, currency, source (a card token, never the raw card number)
Assuming a big vendor probably supports refunds. Probably is not an endpoint, and building a refund flow on an assumption the docs do not back is how an integration stalls after you have committed dates.
Reading only the charge page and never the endpoint index. The answer to can it refund is in the list of what exists, and you only see the gap when you look at the whole surface.
Taking the salesperson's yes over the docs. The docs are the written contract their engineers built against, and the call is where optimistic answers get made, so confirm on the record.
Not writing down that refunds are manual before scoping. If the finding does not make it into the plan, someone estimates automated refunds anyway and the hole reappears mid-build.
Walk into the call and say: "Your docs list charge and retrieve but no refund endpoint, so we read refunds as manual only. Can you confirm there is no refund API?" You answered a vendor-capability question from the docs before pulling anyone in, which is the whole reason a PM learns to read them.
Where a PM meets this
Evaluating a vendor? Skim their API docs. Clear, complete docs are a strong signal; vague ones predict a hard integration.
"Can their API even do that?" is often answerable by you in ten minutes with their docs, before pulling in an engineer.
Hear it in a meeting
"Their docs don't mention refunds, so we may not be able to automate them."