Paste the Real API Docs Before Claude Writes the Client

A grounding step: paste the actual endpoint reference — routes, request/response shapes, auth, error codes — into the context before asking Claude to write the integration, instead of relying on what it remembers about the API.

APIs change, and a model's memory of a third-party API is a snapshot that may be months or years stale. Left to recall, Claude confidently invents plausible-but-wrong endpoints and field names, and you lose an hour to 404s. Given the real spec in context, it writes against what the API actually is today. This is the single highest-leverage move for integration work.

Any integration with a service whose docs you can copy — REST endpoints, SDK methods, webhook payloads, model APIs. Especially for newer or recently-changed APIs.

Extremely well-known, stable interfaces where recall is reliable (e.g. fetch, basic fs). And when the docs are enormous — paste the relevant endpoints, not the whole reference.

Here is the API documentation for the endpoints I need:
<paste the relevant routes, params, response shapes, auth, error codes>

Write a typed client for <language/framework> that:
- covers these operations: <list>,
- handles auth as documented,
- maps documented error codes to typed errors,
- and does NOT call any endpoint or field not present above. If something I need isn't in these docs, tell me instead of guessing.

For a payments provider, pasting the three endpoints you actually use gets you a client with the correct idempotency-key header and the real amount_minor field — versus the un-grounded version that invents an amount float and a signup flow that was deprecated last year.

Add the provider's error-code table and ask Claude to generate the retry policy from it — retry 429 and 5xx with backoff, never retry 4xx — so error handling comes from the spec, not from a generic template.

• Assuming the model 'knows' a fast-moving API and shipping its guess.
• Pasting a giant reference and burying the three endpoints that matter.
• Not including error codes, so the client treats every failure the same way.