You can now read a request (Lesson 13.2) and a response (Lesson 13.3). The remaining question is practical: when you face a new service, where do the endpoint names, field spellings, limits, and examples actually live? In the API documentation — the product manual written for software, and the most trustworthy source for what is true right now.

Why docs beat memory, tutorials, and guesses

Endpoint names change. Fields get renamed. Limits tighten. A blog post from last year may show a path that no longer exists, and a model (including yours) may confidently recall a field the provider removed.

The official docs are the contract at the counter: current endpoint names, required field formats, authentication method, error meanings, and rate limits, usually with copyable examples. When docs and memory disagree, docs win. When two tutorials disagree, docs settle it. Build the habit of opening the manual before reaching for code.

Anatomy of a useful docs page

Most good documentation has the same sections. Learn the map once and every provider feels familiar:

Job in plain English → endpoint reference → auth section
→ quickstart example → schema (request + response)
→ error guide + limits → changelog if confused

If a page lacks half of these, treat that as information: the integration will need more testing and a narrower boundary.

The read-before-build workflow

Do not write code first and read docs after the error. Run these six steps:

1. State the job in plain English. "Get Apple's last 10-K accession number." One sentence, no jargon. 2. Find the relevant endpoint. Scan the endpoint reference for the verb that matches — list, retrieve, create. 3. Read the authorization method. Key in header? Token? OAuth? This decides what setup the call needs (full treatment in Class 14). 4. Copy the smallest official example. Run it unchanged if you can. Prove the counter works before customizing the order. 5. Adapt one variable at a time. Change the CIK, then the field list, then the filter — never all three at once. 6. Inspect the actual response. Status first, then body fields, then headers if limited. Save what worked.

Step 5 is where beginners lose hours: three simultaneous changes and a failure means three suspects. One change means one suspect.

Make your agent use docs responsibly

Your coding agent can read docs fast — but "connect this API" is too vague a brief. Give it a bounded instruction instead:

That sentence does four things: pins the source (official page, not memory), demands a summary (fields + auth), restricts the blast radius (read-only), and requires a pause (propose, don't send). You review the proposal against the six steps above, then approve the test. This is the same report-don't-retry rule from Lesson 13.3, applied before the first call instead of after a failure.

Where providers live, and what SDKs are

A navigation note for the road ahead: the ByeBuy Data directory is where you will compare current providers by category — financial, SEC filings, real estate, government, weather, maps, sports, news, ecommerce, travel, scientific, and social data. The division of labor is clean: Part V teaches how to call and control an API; Part VI teaches whether the underlying data is worth using. Never pick a provider from a single anecdote in a Tools lesson — check the directory.

You will also meet SDKs — official libraries that wrap API calls in your language's functions. Instead of hand-writing HTTP, you call client.orders.create(...) and the SDK builds the envelope. Useful, but not magic: underneath, the same request and response flow, with the same auth, same fields, and same access boundary. An SDK never removes the need to understand what it sends on your behalf.

Practical exercise: write a one-page integration brief

Pick one official docs page — SEC EDGAR, OpenRouter, or any provider in the Data directory. Produce a brief with exactly these lines:

• Endpoint + method
• Required fields
• Authentication mechanism
• Success response (status + key fields)
• Rate limit
• One likely failure and its fix

Finish line: a one-page brief (Markdown or notebook) with all six lines filled, each traceable to a docs section you name.

Verify: hand the brief to someone (or your agent) and ask: could they send the read-only test without asking you a follow-up question? If not, the gap names the section to re-read.

Common failure mode: briefing from a tutorial instead of the official page. If your endpoint or field name cannot be found in the docs, it does not exist — no matter how convincing the tutorial sounded.

Check your understanding

1. Why are official docs more trustworthy than a tutorial or a model's memory? 2. Which docs section answers "how do I prove who I am," and which answers "how many calls may I make?" 3. What are the six read-before-build steps, and why adapt only one variable at a time? 4. What should you ask an agent to do with a docs page — and what must it not do yet? 5. What is an SDK, and why doesn't it remove the need to understand requests and access boundaries?