Generate a Typed Client From the Schema

An integration pattern where you give Claude the API's schema — an OpenAPI spec, a GraphQL schema, or even a few real response payloads — and have it generate typed models plus a thin client, instead of hand-writing untyped fetch calls scattered through your code.

Untyped API calls push failure to runtime: a renamed field or a null you didn't expect surfaces as a crash in production. Deriving types from the schema moves those failures to compile time and gives you autocomplete over the real shape. Claude is good at turning a spec or sample payloads into faithful types and a small wrapper, so the integration is typed end to end from day one.

Integrating any non-trivial third-party or internal API you'll call from several places, especially one with a published schema or stable response shapes worth pinning down.

A single one-off call, or an API so unstable that today's schema won't match tomorrow's response — there, defensive parsing beats generated types that lie. Prefer official generators when the vendor ships a good one; use Claude to fill the gaps.

Here is the API's schema (or representative responses): <paste>.

Generate typed models for these responses and a thin client with one typed method per endpoint I need: <list endpoints>. The client should parse/validate responses against the types and throw a clear error on mismatch. Keep it dependency-light and match my codebase's existing HTTP and error conventions: <paste a sample of ours>.

From a payments API's OpenAPI file, Claude generates Charge and Refund types and a client with createCharge() and refund(). When the vendor later renames a field, your build breaks at exactly the call sites that use it — a compile error you fix in minutes instead of a 2am incident.

Have Claude add a runtime schema validator (such as a parsing layer) at the client boundary so responses are checked against the types at the edge, not just assumed. Generated types describe what should arrive; a boundary validator catches the day the API disagrees.

• Trusting generated types without runtime validation, so a schema drift passes the compiler and corrupts data downstream.
• Generating the client in a style that clashes with your codebase — give Claude a sample so error handling and naming match.
• Scattering raw fetch calls anyway 'just this once', defeating the single typed boundary you built.