OpenAPI editor with linting, versions and sync

Formats and multi-file definitions

The spec editor works with OpenAPI 3.0 and 3.1, Swagger 2.0, and AsyncAPI 2.x and 3.x, in YAML or JSON. A definition can span several files (up to 100) with $refs between them; one file is marked as the root. The bundled view resolves references across files into a single document when you need to hand it to another tool.

Linting that points at the line

Validation runs on the server and reports errors and warnings with the file, line, JSON path and rule that triggered them: parse errors, unresolved $refs, invalid versions, and structural problems in paths, operations, components and channels. Click an issue to jump to it. You can lint unsaved changes too, so mistakes show up before you save.

YAML

openapi: 3.1.0
info: { title: Orders API, version: 1.2.0 }
paths:
  /orders/{id}:
    get:
      operationId: getOrder
      parameters:
        - { name: id, in: path, required: true, schema: { type: string } }
      responses:
        "200":
          description: The order
          content:
            application/json:
              schema: { $ref: "#/components/schemas/Order" }

Generate a collection, then keep it in sync

Generate a collection from a definition with one request per operation, grouped by tags or by path, with example bodies built from your schemas or examples. Generation options cover request naming, folder strategy, optional parameters, deprecated operations and OpenAPI 3.1 webhooks.

When the definition changes, sync instead of regenerating: the merge is keyed on METHOD /path, so request ids, test scripts, auth, saved examples and parameter values you edited are kept, new operations are added, and requests whose operation disappeared are kept as orphans unless you choose to remove them. A sync report lists what was added, updated, removed or orphaned.

Contract tests from the definition

Generate contract tests for the linked collection: for each operation, a test that the response status is one the definition documents, that the content type matches, and that the JSON body validates against the documented schema. They are written into a marked block of each request's test script, so regenerating replaces only that block.

Versions and changelogs

Tag the current files as a version, for example v1.2.0, with release notes. Each version records a changelog against the previous one (added, changed and removed operations), you can diff versions line by line, and restore an older version if needed. Specs deleted by mistake go to the workspace trash first.

How it works

Create a spec in the app, or import an OpenAPI, Swagger or AsyncAPI file.
Edit it with live linting and fix the reported issues.
Generate a collection, add tests, and publish documentation or start a mock server from it.

Specs are stored in cloud workspaces, which need a free account, and are shared with your team with the workspace's roles.

Frequently asked questions

Does it support OpenAPI 3.1?

Yes, along with OpenAPI 3.0, Swagger 2.0 and AsyncAPI 2 and 3.

Will syncing overwrite my tests?

No. Sync keeps request ids, scripts, auth, examples and edited values. Only the "replace" mode regenerates requests from scratch, and you choose it explicitly.

Can I export a collection back to OpenAPI?

Yes. Collections export to OpenAPI 3 in JSON or YAML; see import and export.

Is there a limit on spec size?

Each file can be up to 2 MB by default, with up to 100 files per spec and 500 specs per workspace.

API design with an OpenAPI editor, linting and collection sync