JSON Schema

SchemaMode::Input uses input aliases, input requirements, and the extra-field policy. SchemaMode::Output uses output aliases, removes excluded fields, and requires every field that is actually emitted. Recursive models use $defs/$ref, with definition names containing the full Rust type path. Trimming, coercion, custom functions, and the specific regex/email implementations require Rydantic’s runtime. Exported schemas mark these behaviors with x-rydantic-local-rules; schema_report(mode) returns their locations and rules. Input constraints affected by transformations use a permissive structural description, while output schemas describe the processed data. Literal defaults appear as annotations only in input schemas. Schema generation never executes default factories.

let report = User::schema_report(rydantic::SchemaMode::Input);
for local in &report.local_rules {
    println!("{}: {}", local.schema_path, local.rule);
}

Schemas can describe API documentation and tool arguments. Use model parsing at execution boundaries to run the local rules.

Runtime dynamic schemas

The optional dynamic feature uses jsonschema to compile and reuse schemas at runtime. Network and file resolution are disabled in the default dependency configuration; local $ref references are supported.

rydantic = { version = "=0.7.0", features = ["dynamic"] }

use rydantic::{json, DynamicModel};

let model = DynamicModel::compile(json!({
    "type":"object",
    "properties":{"age":{"type":"integer","minimum":18}},
    "required":["age"],
    "additionalProperties":false
}))?;

assert!(model.is_valid(&json!({"age":25})));
assert!(model.validate(&json!({"age":17})).is_err());

DynamicModel::compile rejects schemas containing x-rydantic-local-rules. compile_structural explicitly opts into standard JSON Schema assertions only. Dynamic validation follows the backend’s default format-annotation semantics and preserves the input. Typed models handle default filling and coercion.

Generate Rust from a schema

The workspace also contains rydantic-codegen, an unpublished developer tool (publish = false). It is not included in the core release archives or available as a crates.io install. Use it from a repository checkout only after reviewing its deliberately limited JSON Schema 2020-12 subset, resource limits and validation semantics. This is not an OpenAPI/Protobuf generator or a drop-in replacement for datamodel-code-generator. Unsupported keywords and references are rejected rather than silently ignored; generated models still require ordinary Rydantic validation. The tool guide documents accepted inputs and safe output handling, including writing to a new temporary file so a failed command does not truncate an existing destination.

OpenAPI 3.1 model components (unreleased)

The repository’s optional openapi feature provides model-component assembly. It is not included in published stable 0.7.0 or core 0.8.0-beta.1. Use a reviewed repository checkout; no new package version is implied by this documentation.

use rydantic::{schema::openapi::OpenApiComponents, Model, SchemaMode};

let mut components = OpenApiComponents::new();
let input = components.insert::<User>("UserInput", SchemaMode::Input)?;
let output = components.insert::<User>("UserOutput", SchemaMode::Output)?;

input.reference and output.reference are schema references for request and response bodies. Put components.into_schemas() specifically at the complete OpenAPI document’s components.schemas location. It returns that map, not an entire components object or document. These references are not standalone JSON Schemas, and moving the map elsewhere breaks their document-root pointers. Use OpenAPI 3.1 with its standard 2020-12-based dialect; do not introduce an ancestor $id or alternate dialect that changes reference resolution. The runnable assembly example constructs openapi: "3.1.1", info, a manually declared path, and both components:

cargo run --locked -p rydantic --example openapi_components --features openapi

Each component retains its own $defs; references are relocated without merging model definitions or dropping assertions. Register input and output views under different names. Component names must match [A-Za-z0-9._-]+; duplicates fail without replacing existing entries. Runtime-only rules remain in the schema and in ComponentRef.local_rules, whose paths are plain JSON Pointers relative to the full document. Consumers do not automatically execute those rules; keep Rydantic parsing/validation at application boundaries. The adapter traverses standard 2020-12 schema locations only, preserving defaults, examples, constants, enums and unknown extension values as opaque data. Custom vocabularies are not supported. It rejects resource IDs, anchors, dynamic/recursive references, external references, unsupported dialects, nested dialect declarations, legacy definitions/dependencies/additionalItems, malformed or dangling pointers, and references into data rather than schema nodes. Schema nesting is bounded at 128. Missing root dialect declarations assume 2020-12; boolean schemas are preserved. Caller-supplied custom JsonType implementations remain responsible for valid assertions: this adapter is not a general schema validator. This is bounded OpenAPI 3.1 model interoperability, not OpenAPI 3.0 conversion, route discovery, full-document validation/import, Swagger UI, client SDK generation or server generation. The reference-resolution tests validate payloads against assembled schema references; they do not certify every OpenAPI tool or prove runtime-rule equivalence.

Start here

Define your model

Control its behavior

Work with JSON

Runtime dynamic schemas

Generate Rust from a schema

OpenAPI 3.1 model components (unreleased)

​Runtime dynamic schemas

​Generate Rust from a schema

​OpenAPI 3.1 model components (unreleased)

Runtime dynamic schemas

Generate Rust from a schema

OpenAPI 3.1 model components (unreleased)