SpecLynx ApiDOM

Semantic parser for API specifications

Who is it for

If you're a JavaScript or TypeScript developer looking for tooling to parse, validate, transform, or build on top of OpenAPI, AsyncAPI, Arazzo, JSON Schema, or other API specifications — you're in the right place.

The problem you know too well

API specifications aren't one thing. There's OpenAPI 2.0, 3.0, and 3.1 — each with breaking differences. There's AsyncAPI for event-driven APIs. Arazzo for API workflows. JSON Schema across multiple drafts. And every one of them can be written in JSON or YAML.

If you've built tooling for this world, you've felt the pain. You write a parser for OpenAPI 3.0 in YAML, then realize you need 3.1. Then someone sends a JSON file. Then your team adopts AsyncAPI for their event bus. Each new format means new parsing logic, new data structures, new edge cases.

Your actual tooling logic, the part that does something useful, gets buried under format-specific plumbing.

What ApiDOM does

Think of Babel for JavaScript: it parses any JS syntax into a single AST, and an entire ecosystem of tools works against that AST without caring about the source. ApiDOM does the same for API specifications.

It parses any supported API description into a unifying structure with namespaces for each specification. OpenAPI 3.1 in YAML, AsyncAPI 2.6 in JSON, an Arazzo workflow — each gets its own namespace, but they all share the same foundation. Your tooling code works the same way regardless of the input.

But it's not just a generic tree of objects and arrays. ApiDOM produces semantic elements — nodes that know what they represent. An element knows it's an OpenAPI Operation, a Schema Object, or a Server URL. Your code works with the API's meaning, not its raw syntax.

ApiDOM is lossless

Most parsers throw things away. Comments disappear. Key ordering changes. Whitespace gets normalized. If you parse a YAML file and serialize it back, what you get out is not what went in.

ApiDOM has been designed to retain all of that low-level detail. Comments, original key ordering, format styles, and raw CST source texts — everything is preserved in the element tree. Every semantic element carries source maps with full positional data using UTF-16 code units, making them directly compatible with the Language Server Protocol, VSCode, and Monaco Editor.

Precise diagnostics that point to the exact line and column. Modifications that don't silently rewrite the rest of the file. Comments, formatting, and key ordering that survive every round-trip.

Where it comes from

ApiDOM started as an internal tool inside a large API company, born from the day-to-day needs of building and maintaining API tooling at scale. We hit every limitation you can hit: parsers that couldn't round-trip without losing data, format-specific code paths that multiplied with every new specification version, tooling that broke silently when the underlying structure changed.

That internal tool was eventually open-sourced. SpecLynx ApiDOM is its next evolution — a complete rewrite that takes everything we learned from years of battle-testing and distills it into a library that solves these problems once, so you don't have to.

Built on ApiDOM

We use ApiDOM ourselves. The rest of the SpecLynx ecosystem is built directly on top of it:

Frequently Asked Questions