OpenAPI 3.1 output
Generate a modern API specification in portable YAML or JSON.
Start typing to search 139 tools.
Generate an OpenAPI 3.1 document from endpoint settings and JSON request or response samples.
OpenAPI Generator is a powerful online OpenAPI Generator for developers who need a fast starting point for API documentation, SDK generation, testing, and collaboration. It converts endpoint settings plus realistic JSON samples into a structured OpenAPI 3.1 document without sending the source to an external API.
The OpenAPI Generator can create YAML or JSON output, infer nested JSON Schema structures, include request bodies, define successful JSON responses, configure servers, and add Bearer token or API key authentication. This makes it useful when documenting a new endpoint, preparing a prototype, migrating handwritten API notes, or creating a specification that will later be refined in an API design platform.
Generated schemas are inferred from examples, so every result should be reviewed. A single JSON sample cannot reliably determine every nullable property, optional field, enum, format, error response, pagination rule, or business constraint.
Focused controls, predictable output, and a workflow designed around this exact transformation.
Generate a modern API specification in portable YAML or JSON.
Infer nested objects, arrays, primitive types, and common string formats from JSON examples.
Add Bearer token or X-API-Key security schemes without writing the structure manually.
Copy or download the generated document for validators, documentation systems, and code generators.
Practical details about input, output, privacy, limits, and the best way to use this tool.
OpenAPI Generator creates an OpenAPI 3.1 document from endpoint settings and JSON request or response examples. The result can be used as a starting point for API documentation and tooling.
Swagger originally described both a specification and a group of tools. The specification is now called OpenAPI, while Swagger remains a common name for tools built around it.
Yes. Select YAML for a readable specification or JSON for systems that prefer JSON input.
Yes. Nested objects, arrays, integers, numbers, booleans, null values, and common string formats are inferred from the provided samples.
Yes. Paste an optional JSON request sample and the tool will create an application/json requestBody schema and example.
The generator can add a Bearer HTTP security scheme or an API key passed through the X-API-Key header.
No automated generator can infer every contract detail from one example. Review optional fields, validation rules, error responses, pagination, examples, descriptions, and security requirements.
No external API is required for generation. Processing occurs within the Trexmi tool workflow.
OpenAPI Generator creates an OpenAPI 3.1 document from endpoint settings and JSON request or response examples. The result can be used as a starting point for API documentation and tooling.
Swagger originally described both a specification and a group of tools. The specification is now called OpenAPI, while Swagger remains a common name for tools built around it.
Yes. Select YAML for a readable specification or JSON for systems that prefer JSON input.
Yes. Nested objects, arrays, integers, numbers, booleans, null values, and common string formats are inferred from the provided samples.
Yes. Paste an optional JSON request sample and the tool will create an application/json requestBody schema and example.
The generator can add a Bearer HTTP security scheme or an API key passed through the X-API-Key header.
No automated generator can infer every contract detail from one example. Review optional fields, validation rules, error responses, pagination, examples, descriptions, and security requirements.
No external API is required for generation. Processing occurs within the Trexmi tool workflow.
The OpenAPI Generator combines your API title, version, server URL, endpoint path, HTTP method, operation summary, operation ID, security selection, and JSON samples. It creates an OpenAPI 3.1 root document with an info object, paths map, operation object, response content, examples, and inferred schemas.
The generated document focuses on one endpoint so it stays understandable. You can merge several generated paths later or use the output as a starting point for a larger specification.
JSON values determine initial schema types. Whole numbers become integers, decimal values become numbers, booleans remain booleans, strings remain strings, arrays receive item schemas, and objects receive properties. Common email, URI, UUID, date, date-time, IPv4, and IPv6 values may receive format hints.
Example-based inference has limits. A property shown in every example may still be optional in the real API. Empty arrays do not reveal their item type, and one string value does not prove an enum. Review every generated schema against application behavior.
Bearer authentication creates an HTTP bearer security scheme with JWT as a descriptive bearer format. API key authentication creates a header-based scheme named X-API-Key. The selected scheme is applied globally in the generated document.
Production APIs may require OAuth 2.0 flows, OpenID Connect, multiple alternative schemes, scopes, mutual TLS, signed requests, or endpoint-specific permissions. Add those details manually when necessary.
Use path /users/{id}, method GET, summary Get a user, and a response such as {"id":1,"name":"Ada","active":true}. The generated response schema includes integer, string, and boolean properties.
Use path /users, method POST, provide a request JSON sample, and paste the created user as the response sample. Then review the generated requestBody and change the response code from 200 to 201 if appropriate.
Examples show observed values, not every possible value. Add constraints, nullable types, descriptions, examples, defaults, enums, and optional fields after generation.
The starter document uses a successful 200 response. Change it to 201, 204, or another status where the real endpoint requires it, and add error responses such as 400, 401, 403, 404, 409, 422, and 500.
A path such as /users/{id} normally requires a matching path parameter definition. Add parameter details, type, description, and required status during review.
Create request commands with cURL Builder, assemble header blocks with HTTP Header Builder, or infer standalone schemas with JSON Schema Generator.
Review the OpenAPI Specification and the JSON Schema documentation before publishing a production contract.