OpenAPI SDK Generator: Generate API Clients From Your Spec Online

Every hand-written fetch()call against an API is a guess about the API's shape, made by a human reading documentation (or, worse, another endpoint's code) and typing out a URL, a set of headers, and a body that should match what the server expects. Nothing checks that guess against reality until the request actually runs. An openapi sdk generator removes the guessing step entirely: it reads the OpenAPI document — the same file the API itself is built from, or validated against — and turns every path, every parameter, every request body and response schema into an actual TypeScript function signature.

That's the real value, and it's worth stating precisely rather than vaguely: when the API changes — a field gets renamed, a previously optional parameter becomes required, a response gains a new discriminated variant — and the client is regenerated from the updated spec, that change shows up as a TypeScript compile error at the call site. Not a 400 response discovered by a user in production. Not a silent undefined read three components deep because a field was renamed and nothing enforced the old name being wrong. The mismatch is caught at build time, in the editor, before the code ships — which is the entire difference between a typed client and a stack of hand-copied fetch calls that happen to work today.

Concretely, this is the transformation: an operation object in an OpenAPI document — a path, a method, a set of parameters, a request body schema, a response schema — becomes one typed async function. The function's parameters are the operation's parameters and body, typed from their schemas; its return type is the response schema, typed the same way. Nothing about the call site requires knowing the URL structure, the HTTP method, or how the request body needs to be serialized — that's all encoded in the generated function.

paths:
  /orders/{id}:
    patch:
      operationId: updateOrder
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: string
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              properties:
                status:
                  type: string
                  enum: [pending, shipped, delivered, canceled]
                note:
                  type: [string, "null"]
      responses:
        "200":
          description: The updated order
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Order"

export interface UpdateOrderBody {
  status?: "pending" | "shipped" | "delivered" | "canceled";
  note?: string | null;
}

export interface Order {
  id: string;
  status: "pending" | "shipped" | "delivered" | "canceled";
  total: number;
  note?: string | null;
}

export async function updateOrder(
  id: string,
  body: UpdateOrderBody,
  init?: RequestInit,
): Promise<Order> {
  const res = await fetch(`/orders/${encodeURIComponent(id)}`, {
    ...init,
    method: "PATCH",
    headers: { "content-type": "application/json", ...init?.headers },
    body: JSON.stringify(body),
  });
  if (!res.ok) throw new Error(`updateOrder failed: ${res.status}`);
  return res.json() as Promise<Order>;
}

The enum on status becomes a TypeScript union, not a bare string — pass a value outside pending | shipped | delivered | canceledand it's a compile error, not a runtime 400 from the server. The path parameter is interpolated and percent-encoded automatically. None of this is novel logic per call site; it's the same handful of decisions, made correctly once by the generator and repeated identically for every operation in the spec.

Look closely at the generated function above: it's plain fetch(), plain JSON.stringify, and two exported interfaces. There's no import from a runtime support package, no custom ApiClientclass instantiated with configuration, nothing beyond what the browser and Node already ship. That's a deliberate choice, not an accident of a simple example — and it's worth contrasting with how most OpenAPI-to-client tooling actually works.

Tools like openapi-generator and several commercial swagger to typescript generators produce a client that depends on a bundled runtime library — a request wrapper, an error class hierarchy, sometimes an entire generated "core" module of hundreds of lines that every operation function imports from. That runtime layer is itself a dependency: it needs to be vendored or installed, it needs its own version tracked against the generator that produced it, and it's additional surface area in a supply-chain sense — code running in your application that you didn't write and that isn't just a typed description of an HTTP call.

A generator that emits zero-dependency, fetch()-based code sidesteps all of that. The output is plain TypeScript source — readable top to bottom in a few minutes, auditable the same way any other file in the repo is, and safe to commit directly into the codebase rather than installed as a package with its own update cadence. If the generated client needs a small change — a custom header, different error handling — it's a normal edit to a normal file, not a workaround around a generated runtime's extension points.

This is the single most important design decision behind any openapi typescript client generator, and it's the one most tooling gets wrong in a way that's easy to miss until it costs someone a debugging session. An OpenAPI document can leave a schema genuinely ambiguous — additionalProperties: true with no defined shape at all, or a oneOf across several variants with no discriminator the generator can safely use to tell them apart at runtime. When that happens, there are exactly two honest options: type the field as something wide and clearly provisional, like unknown or a documented any, or refuse to guess and say so.

There is a third option, and it's the dishonest one: fabricate a specific-looking type anyway, inferred from a single example value in the spec or from a guess about what the field "probably" contains. That third option is worse than either honest one, because the resulting type looksprecise — it autocompletes fields, it appears to type-check — while guaranteeing nothing the spec actually promises. Code written against a fabricated type compiles cleanly and then breaks the first time a real response doesn't match the shape the generator invented, which is a strictly worse failure mode than an honest unknown that forces a runtime check before the value is used.

# spec: no defined shape, and no discriminator to pick a variant safely
metadata:
  additionalProperties: true

variant:
  oneOf:
    - $ref: "#/components/schemas/CardPayment"
    - $ref: "#/components/schemas/BankTransfer"
  # no discriminator — the generator cannot safely tell which variant a given
  # response actually is without one, so it will not pretend it can

↓ generated

interface Order {
  metadata: unknown; // schema left this fully open — narrow it yourself before use
  variant: unknown;  // oneOf with no discriminator — reported, not guessed at
}

GenKitLab's OpenAPI SDK Generator works this way on purpose: it turns an OpenAPI 3 document into a typed, dependency-free TypeScript fetch client, and it shows you exactly which parts of the spec were too vague to type precisely, rather than quietly inventing precision that was never actually guaranteed. Everything runs client-side in your browser — the spec you paste or drop in is never uploaded anywhere.

A generator can only be as honest about ambiguity as the spec lets it be — and a spec with structural errors doesn't produce an honestly-ambiguous client, it produces an unpredictable one. A response object missing its schema entirely, a $refthat points at a component that doesn't exist, a parameter with an invalid invalue: these aren't edge cases a generator can reason about carefully, because they mean the document itself doesn't describe a valid API in the first place. The fix isn't a smarter generator; it's validating the spec first.

That's the natural order for this whole workflow, covered in full in the OpenAPI Validator guide: confirm the document is structurally valid — every required field present, every reference resolved — before handing it to a client generator, a mock server, or anything else downstream that assumes a well-formed spec as its starting point. GenKitLab's OpenAPI Validator checks exactly that, with every error located by JSON Pointer, and it's the same client-side, nothing- uploaded approach as the SDK generator itself — the two tools are built to be run back to back on the same document.