Kayto

Fast OpenAPI parser and schema generator that turns imperfect specs into stable artifacts with human-readable diagnostics.

From imperfect OpenAPI to production-ready schema in minutes.

Features

• ⚡ Fast best-effort parsing for real-world OpenAPI specs.
• 🧠 Clear, actionable diagnostics that help you fix spec issues faster.
• 🧩 Stable IR layer between parser and language generators.
• ✅ TypeScript and Dart generators with endpoint metadata output.
• 🛡️ Generation keeps working even when parts of the spec are unsupported.
• 🧪 Snapshot and unit tests for parser and generators.

What It Does

kayto parses OpenAPI, builds an internal IR, and passes that IR to language generators.

Core concept:

OpenAPI Spec (v2/v3, partial) ✅
        |
        v
      Parser ✅
        |
        v
        IR ✅
        |
        v
   Generators
   (ts ✅, dart ✅, ...)
        |
        v
  Output Artifacts ✅
 (generated/schema.ts, ...)
        |
        v
  API Client Libraries
   (separate projects 🚧)

Why Kayto

• Works even when OpenAPI is incomplete or inconsistent.
• Keeps one stable schema contract (Schemas + Endpoints) across projects.
• Lets teams integrate API clients quickly without custom parser glue.

Current Status

• ✅ TypeScript generator (schema.ts)
• ✅ Dart generator (schema.dart)
• ✅ Best-effort parsing with graceful fallback to unknown
• ✅ Structured diagnostics with stable issue codes

Note: Kayto targets practical API coverage, not full OpenAPI v2/v3 spec compliance.

Quick Start

CLI arguments are required: --lang, --input, --output.

TypeScript:

cargo run -- --lang ts --input "https://raw.githubusercontent.com/github/rest-api-description/main/descriptions/api.github.com/api.github.com.json" --output "generated/schema.ts"

Dart:

cargo run -- --lang dart --input "https://raw.githubusercontent.com/github/rest-api-description/main/descriptions/api.github.com/api.github.com.json" --output "generated/schema.dart"

Helper scripts:

./scripts/generate-ts.sh
./scripts/generate-dart.sh

Scripts support optional args:

./scripts/generate-ts.sh [output_path] [input_url]
./scripts/generate-dart.sh [output_path] [input_url]

Defaults are provided by scripts:

• TS: generated/schema.ts + GitHub public OpenAPI JSON
• Dart: generated/schema.dart + GitHub public OpenAPI JSON

Generated TypeScript Model

The TS generator writes schema.ts with:

• Schemas interface: map of model names (Schemas["UserModel"]).
• Endpoints interface: endpoint metadata by method/path (Endpoints["get"]["/path"]).
• Reuse of Schemas[...] in endpoint params/body/responses.

Example:

import type { Endpoints } from "./schema";

type GetUser = Endpoints["get"]["/user"];

Generated Dart Model

The Dart output is built for simple client usage:

• quick endpoint access (Endpoints.get.user or Endpoints.get['/user']),
• one consistent schema contract across projects,
• easy integration into API clients with minimal glue code.

Example:

import 'schema.dart';

final endpoint = Endpoints.get.user;

Kayto Schema Standard

Kayto output is a stable contract designed for long-term maintenance:

• predictable structure (Schemas + Endpoints),
• easy client integration without per-project parser logic,
• stable generated shape across releases to reduce integration churn.

In short: generated schemas are reusable infrastructure, not throwaway code.

Diagnostics

Diagnostics are built for fast debugging:

• show exactly which endpoint has a problem,
• explain what went wrong in plain text,
• keep stable issue codes for automation/CI,
• provide a short summary of unsupported schema parts.

You can quickly see what to fix now and what can stay as-is for later.

Roadmap

Planned generator targets:

• Swift
• Kotlin
• C#
• Go
• Rust

Client SDKs as separate projects:

• kayto-ts
• kayto-dart

Distribution and developer experience:

• Publish release binaries for major platforms so Kayto can be installed and used directly as a CLI tool.
• Improve docs for working with many different Swagger/OpenAPI services in real projects.
• Add support for local spec files (.json / .yaml) in addition to HTTPS input.

Tests

Run:

cargo test

Coverage (cargo llvm-cov --workspace --summary-only):

• Regions: 81.68%
• Lines: 86.39%
• Functions: 91.11%

Covers most practical parser/generator scenarios. Main gaps: runtime/network paths in main.rs and a few deep edge branches.