* 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>
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-leveltypemust becollection.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/.