Files
Curry YangandClaude Opus 5 59d832ba10 Fix/socket io&websocket payload in export (#10634)
* fix: carry Socket.IO and WebSocket payloads through the v5 format [INS-3123]

A Socket.IO request's body (event name, ack, args) lives in its own
SocketIOPayload document rather than on the request, and the Insomnia v5
YAML format did not represent it at all. WebSocketPayload has the same
shape and the same gap.

Duplicating a collection goes through a v5 export/import round-trip, so
the payload was silently dropped and the copy came back with an empty
Body tab while url and headers survived.

The same gap is worse under Git Sync projects: `deleteOrphans` removes
every workspace descendant that is `canSync` and absent from the imported
file, and the importer could never produce a payload. A `git pull`, a
checkout, an edit to any part of the YAML, or merely restarting the app
therefore deleted them. Editing a payload in the app never wrote to disk
either, since the exported YAML did not change, so those edits only ever
existed in the database until the next sync removed them.

Both request nodes now carry an optional `body` holding the payload
document's own id, so a re-import updates the same document instead of
orphaning it. An untouched payload is omitted entirely: opening a
Socket.IO request creates an empty payload document, and writing that out
would add a spurious block and a git diff to every repository.

The branches of `RequestCollectionSchema` are told apart only by the
`meta.id` prefix, and `z.object` strips unknown keys rather than
rejecting them, so a node without `meta` matched the WebSocket branch and
lost its Socket.IO-only keys — `eventListeners` already went this way.
Extend the existing `z.undefined()` guard idiom to cover them.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* fix: export Socket.IO requests from design documents

The design-scope export filter listed request groups, HTTP, WebSocket and
gRPC requests but not Socket.IO ones, so a Socket.IO request created in a
design document vanished from its YAML.

Under a Git Sync project that is data loss rather than a missing field:
the request is absent from the imported file, so `deleteOrphans` removes
the request document itself on the next sync.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* test(smoke): assert the Socket.IO body survives import

The fixture had a Socket.IO request whose body the v5 format could not
express, so the smoke test connected and sent nothing. Give it an event
name and a payload, and assert both are populated after importing.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* fix comment

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
2026-10-22 07:30:58 +00:00
..
…

Insomnia File Schema

insomnia.schema.5.1.json is a JSON Schema (draft 2020-12) describing the Insomnia v5 file format — the .yaml files you get when you export a collection, design document, environment or mock server, and the files Insomnia reads and writes in Git-backed repositories.

Use it to validate and autocomplete Insomnia files in your editor or CI, and to give AI agents a precise contract for the files they generate.

The schema is generated from Insomnia's source of truth (the Zod schema in packages/insomnia/src/common/import-v5-parser.ts). Do not edit the schema files by hand — see Regenerating.

Versioning

Each schema version is published as its own immutable file, insomnia.schema.<version>.json (e.g. insomnia.schema.5.1.json). Bumping the schema adds a new file next to the existing ones, so every version stays addressable and no published URL ever changes meaning. The current version is defined by INSOMNIA_SCHEMA_VERSION in schema-version.ts.

Reference the specific version you target — when the schema bumps, update the version in the URL to move forward.

Stable URL

The schema is published as a raw file on the default branch:

https://raw.githubusercontent.com/Kong/insomnia/develop/schemas/insomnia.schema.5.1.json

This is the value of the schema's $id and the URL you should reference below. To pin a specific app version, swap develop for a release tag (e.g. core@12.0.0).

What it covers

A single top-level type field discriminates the five file kinds:

type File kind
collection.insomnia.rest/5.0 Request collection
spec.insomnia.rest/5.0 API spec / design document
mock.insomnia.rest/5.0 Mock server
environment.insomnia.rest/5.0 Global environment
mcpClient.insomnia/5.0 MCP client

Usage

VS Code (YAML extension)

Install the YAML extension and map your Insomnia files to the schema in .vscode/settings.json:

{
  "yaml.schemas": {
    "https://raw.githubusercontent.com/Kong/insomnia/develop/schemas/insomnia.schema.5.1.json": [
      "**/*.insomnia.yaml",
      ".insomnia/**/*.yml"
    ]
  }
}

You can also point a single file at the schema with an inline modeline comment:

# yaml-language-server: $schema=https://raw.githubusercontent.com/Kong/insomnia/develop/schemas/insomnia.schema.5.1.json
type: collection.insomnia.rest/5.0
name: My Collection

Command line / CI

Validate a file with any JSON Schema validator. Example with ajv-cli (the file is YAML, so convert it first — e.g. with yq):

curl -sO https://raw.githubusercontent.com/Kong/insomnia/develop/schemas/insomnia.schema.5.1.json
yq -o=json '.' my-collection.insomnia.yaml > my-collection.json
ajv validate --spec=draft2020 -s insomnia.schema.5.1.json -d my-collection.json

Node.js

import Ajv2020 from 'ajv/dist/2020.js';
import addFormats from 'ajv-formats';
import { readFileSync } from 'node:fs';
import YAML from 'yaml';

const schema = JSON.parse(readFileSync('insomnia.schema.5.1.json', 'utf8'));
const ajv = addFormats(new Ajv2020({ allErrors: true, strict: false }));
const validate = ajv.compile(schema);

const data = YAML.parse(readFileSync('my-collection.insomnia.yaml', 'utf8'));
if (!validate(data)) {
  console.error(validate.errors);
  process.exit(1);
}

AI agents

When asking an agent to author or edit an Insomnia file, give it the schema URL as the contract to follow and validate against:

Generate an Insomnia collection that conforms to the JSON Schema at https://raw.githubusercontent.com/Kong/insomnia/develop/schemas/insomnia.schema.5.1.json. The top-level type must be collection.insomnia.rest/5.0.

Regenerating

The schema is regenerated from the Zod source and committed. CI fails if the committed file drifts from the source (see .github/workflows/test.yml). After changing the Zod schema, run:

npm run generate:schema -w insomnia

and commit the updated files in schemas/.