Supported OpenAPI and Swagger schemas
The converter handles the schema patterns that usually block a TypeScript integration review: objects, required fields, optional fields, arrays, enums, nullable values, local references, and simple oneOf/anyOf unions. It accepts OpenAPI 3.x component schemas and legacy Swagger 2.0 definitions.
- OpenAPI 3.x `components.schemas` and local `$ref` component references.
- Swagger 2.0 `definitions` for older API contracts.
- Zod validators plus inferred TypeScript types for parsed payloads.
- Diagnostics for custom formats and complex polymorphic schemas that need review.
OpenAPI 3.0 vs 3.1 nullable fields
Nullable handling is one of the highest-risk conversion details. OpenAPI 3.0 often uses `nullable: true`, while OpenAPI 3.1 can use JSON Schema style type unions such as `type: ["string", "null"]`. FrameworkKit maps supported nullable fields to `.nullable()` and keeps optional properties separate from present-but-null values.
- Use `.nullable()` when the API can return `null`.
- Use `.optional()` when the property can be omitted.
- Use fixtures from real API responses to confirm nullable and optional behavior before shipping.
$ref, shared components, enums, and arrays
Shared OpenAPI components should stay readable after conversion. Local `$ref` values are rendered as references to generated schema exports, enums become closed choices, arrays preserve their item schema, and required arrays control which object keys remain mandatory.
- Keep component names stable so generated schema names stay stable.
- Review circular references and deeply nested components before copying output.
- Check enum values against production payloads, not only against documentation examples.
oneOf and anyOf limits
Simple unions can become Zod unions, but complex oneOf/anyOf structures need a human pass. Discriminators, overlapping object members, and allOf-style inheritance can change runtime behavior if a generator guesses too aggressively.
- Prefer discriminated unions when the API has a stable type field.
- Add fixture tests for each union branch.
- Keep diagnostics visible in pull requests when a schema needs manual review.
Schema coverage checklist
Review required fields, nullable values, enums, arrays, local references, and object strictness before copying generated validators into production code.
- Use fixtures for successful and failed API responses.
- Check nullable OpenAPI 3.0 and 3.1 fields carefully.
- Document unsupported custom formats before release.
Swagger 2.0 migration path
When a team still has Swagger 2.0 definitions, generate Zod schemas from definitions first, then compare the output with the OpenAPI 3 components you plan to publish.
Typed client boundary
The safest workflow is to validate raw network data before it reaches React components, tRPC procedures, cache layers, or service code. Use inferred Zod types after parsing, not before.
FrameworkKit vs openapi-zod-client, Orval, and Kubb
If you are evaluating openapi-zod-client, Orval, Kubb, or other OpenAPI generators, FrameworkKit covers the quick schema-conversion and review workflow without installing a package. Reach for code generation when a typed client should be committed and regenerated in CI; use this converter for fast, private schema inspection and copy-ready Zod validators.
Copy-paste validation recipe
The safest production pattern is small: parse network JSON as unknown, validate with the generated Zod schema, log structured issues when parsing fails, and only expose the parsed value to the rest of the app. This keeps OpenAPI as the contract source while TypeScript receives runtime-checked data.
What this tool does
Convert OpenAPI or Swagger schema components into runtime validators for TypeScript applications.
Validate API contracts
Convert OpenAPI components into runtime Zod validators for TypeScript services.
Bootstrap typed clients
Generate validators and inferred types from an existing Swagger or OpenAPI document.
Review schema coverage
Inspect required fields, nullable values, enums, arrays, and local references before integration.
Does OpenAPI to Zod support Swagger definitions?
Yes. The current generator accepts OpenAPI components.schemas and Swagger 2.0 definitions in JSON input.
Is YAML supported?
YAML is planned. The live workflow currently focuses on JSON so validation and diagnostics stay predictable.
Is my API schema sent to a server?
No. The current conversion runs in the browser and does not upload pasted OpenAPI documents.
How is this different from openapi-zod-client?
openapi-zod-client is an npm package that generates a full typed fetch client plus Zod schemas inside your codebase. FrameworkKit is a browser-only converter for quickly turning OpenAPI components into Zod validators and inferred types without installing anything. Use openapi-zod-client when you want a generated client committed to your repo, and use this tool for fast schema conversion and review.