Skip to main content

open source · MIT · v0.1.0

API docs that can execute. audit themselves. replay. remember.

Docs, a try-it console, environments, executable scenarios and a schema audit — generated in the browser from your OpenAPI schema. No backend, no build step, no account.

Your schema URL OAS · SWAGGER · JSON · YAML

Try it — nothing is sent anywhere, your browser does the fetching.

01 · THE TAG

Paste this line — that's the whole install.

1 LINE · NO BUILD · NO BACKEND
<script src="https://cdn.jsdelivr.net/npm/apiglow@0.1.0/dist/app.js" type="module"></script> INS. [01] · CLICK TO COPY

PASTE IT BEFORE </body>POINT THE JSON TAG AT YOUR SCHEMAIT'S LIVE

…plus one JSON tag pointing at your schema. That's the entire install — the copy button grabs both tags at once.

02 · THE START

Go live before your coffee.

No tooling: if you can edit an HTML file, you can deploy ApiGlow.

0:00

Paste the snippet into any HTML page — a static file server is enough.

DEM. [01]

0:10

Your documentation renders: navigation, operations, try-it panel.

DEM. [02]

0:60

First real request sent from the browser.

DEM. [03]

Step three assumes your API allows CORS from the docs origin — that part is between your API and the browser, and ApiGlow tells you plainly when it isn’t the case. See Try-it & CORS.

03 · THE PRODUCT

Ship a product, not a schema viewer.

What you would go get from a paid SaaS — delivered by the tag, rendered in the reader's browser.

04 · THE PROOF

Grade the schema your docs already loaded.

The audit runs on the document actually loaded — not on yesterday's copy in CI.

  • 38 rules over the loaded document (v0.1.0)
  • An A→F grade, category by category
  • Every finding links straight to what it concerns
  • Markdown report export — nothing is sent anywhere

Read more about the schema audit

38 / 38 RULES PASSED

OVERALL GRADE · SCHEMA AUDIT

AUD. [01]
05 · THE WALKTHROUGH

Turn a scenario into an interactive tutorial.

Where the industry answers "chain requests" with JavaScript, ApiGlow answers "click the response". Exchanged as Arazzo — and handed to your CI as a generated GitHub Actions or GitLab job, secrets as names only.

Run it two ways. "Run all" produces a per-step report; step-by-step mode executes each request in the real try-it console, turning an authored scenario into an interactive tutorial.

Scenarios export to and import from Arazzo 1.1, the OpenAPI Initiative's workflow format. As of August 2026, every other Arazzo runner lives in a CLI or a CI pipeline — no other documentation product executes Arazzo in the browser.

Read more about scenarios

1 · POST /auth/token → token201
2 · GET /pets?limit=3 → petId200
3 · POST /orders petId injected201

— NO SCRIPTING. VALUES CHAIN BY CLICKING THE RESPONSE.

06 · THE CONSOLE

Retire the separate client.

Paste a cURL command, a Postman v2.1 collection or a HAR — you land in a pre-filled console.

console — import a request

curl -X POST https://api.example.com/pets -H "Authorization: Bearer …"

→ Pre-filled console · method, headers and body recognized

AVAILABLE EXPORTS: cURL · Postman · Markdown · HAR
HISTORY: local, filterable, replayable (IndexedDB)
SECRETS: redacted by default

cURLPOSTMAN V2.1HARMARKDOWN

Read more about the try-it console

07 · THE PAGES

Move your prose in with the reference.

Guides, tutorials, architecture notes — Markdown files declared in one line, woven into the navigation, rendered in the browser like everything else.

"docsPages": [ { "title": "Getting started", "url": "./guides/start.md" }, { "title": "Architecture", "url": "./ARCHITECTURE.md" }, { "title": "Changelog", "url": "./CHANGELOG.md" } ] // that's the whole configuration
PRO. [01]
MDGetting started
PETS
GET/pets
POST/pets
GET/pets/{id}
MDArchitecture
ORDERS
POST/orders
MDChangelog
PRO. [02]
## Create an orderAuthenticate, then call theoperation right from this guide:```apidoc:operationcreateOrder```
PRO. [03] · GUIDE.MD
Create an order

Authenticate, then call the operation right from this guide:

POST/orders Create an order for a pet Open the operation →
PRO. [04] · RENDERED PAGE
One .md file is enough — static end to end

Point at an existing Markdown file, README or CHANGELOG included. It is fetched like the schema, when it is read: nothing to build, nothing to redeploy beyond your files.

Your pages talk to the reference

apidoc: links with method badges, operation cards, callouts, language-synced code tabs, a ToC, prev/next pages — and prose is indexed into the Cmd+K search.

08 · THE AGENTS

Meet your docs' new readers.

Some readers are agents — or developers pairing with one. ApiGlow generates the take-away files an assistant actually uses, entirely client-side: the app calls no model and runs no server.

TXTllms-full.txt

The whole documentation as one Markdown file — info, servers, prose pages, every operation and every webhook.

AGT. [01]

TXTllms.txt

The index of the same content, per the llmstxt.org convention — one link per operation and webhook, into the page's own routes.

AGT. [02]

JSONMCP server config

A JSON block, a claude mcp add one-liner or a Cursor/VS Code install link — wiring one of two off-the-shelf OpenAPI-to-MCP bridges, your pick. Credentials come out as placeholders.

AGT. [03]

THE PROMPT · HAVE AN AGENT INSTALL IT FOR YOUCLICK TO COPY

Add interactive API documentation to my project with ApiGlow
(https://apiglow.dev).

1. Create a static page (e.g. docs/index.html) containing exactly:
   - a <script id="api-doc-config" type="application/json"> block with:
     { "openapi": { "url": "<my OpenAPI schema URL or relative path>" } }
   - <script src="https://cdn.jsdelivr.net/npm/apiglow@0.1.0/dist/app.js"
     type="module"></script>
2. My OpenAPI schema is at: [FILL IN — URL or path]
3. Serve the page over HTTP(S) — file:// does not work (ES modules).
4. If my API is on another origin, tell me it must allow CORS from the
   docs origin for the try-it console to work.
Config reference: https://apiglow.dev/docs/configuration/
AGT. [04]

Read more about the AI surface

09 · THE BAKE

Serve the crawlers a static mirror.

AI crawlers run no JavaScript, and Google reads every #/ route as one URL. One author-side command writes what they need — the reader's install stays one tag.

apiglow bake — run it from the CI job that deploys your docs

apiglow bake --config apidoc.config.json --site-url https://docs.example.com/ --out public/

→ Baked 26 files into public/ · honest static pages, zero scripts inside

op/addPet.html + .md every operation — canonical, JSON-LD, a link back to the app
scenario/order-a-pet.arazzo.json every scenario as the recipe a CI runner executes
sitemap.xml · llms.txt · llms-full.txt served files, with links an agent can actually fetch

SITEMAPSERVED LLMS.TXTMD MIRRORSJSON-LD0 SCRIPTS

Read more about SEO & crawlability

The API reference that is the API client — environments, variables, history, multi-step scenarios — in one script tag, with no backend and no build step.

THE APIGLOW PRINCIPLE · V0.1.0
10 · THE INVENTORY

And everything else, in the same tag.

Every module is already there — nothing extra to install, nothing to switch on.

Doc/panel mirror — edit the request from the doc column or the panel, always in sync

Environment setup links — onboard a teammate with one URL — built from scratch, without creating the environment

Local schema patch — the reader's own Overlay 1.1, applied last and downloadable as the fix to send upstream

Guides that read personally — {{var}} resolved in prose from the reader's environment — sensitive values never emitted

Failure diagnosis — offline, mixed content, CORS or unreachable, named rather than guessed

Response-header intelligence — rate limits, Retry-After, Deprecation/Sunset, Link pagination, correlation ids

Import a request — paste a cURL command, drop a Postman v2.1 collection or a HAR

First-call onboarding — a generated first request, walked through in the real try-it — opt-in, features.onboarding

Request history — filterable and replayable, kept in the reader's own IndexedDB

Full parameter serialization — style, explode, deepObject, cookies — the boring parts, done right

Swagger 2.0 — converted at load; nothing to run beforehand

Webhooks & callbacks — rendered like operations, with a webhook simulator

JSON Schema 2020-12 — keywords rendered rather than silently dropped

Circular references — handled, in the doc and in the generated examples

Hide internal endpoints — from the schema or the config — documentation hiding, not access control

Your prose pages — markdown guides woven into the navigation, next to the reference

Instant search — Cmd+K, answering in under 200 ms on a 12 MB, 1220-operation schema — a CI-enforced budget

Fully localized UI — a language is one JSON file, downloaded only when it is the active one

Locked environments — environmentsLocked for controlled corporate deployments

Host credentials bridge — the page's SSO session becomes the reader's token — runtime-only, in memory, never stored

CI hand-off — a generated GitHub Actions or GitLab CI job runs a scenario's Arazzo document — secrets as names, never values

Two nav zones — nav: bottom sends support and legal pages below the reference — an appendix, not a second docs section

Accessibility — WCAG 2.2 AA targeted on every interactive path — navigation, try-it, search

No framework — native web components, 5 runtime dependencies, one bundle

Everything stays local — localStorage and IndexedDB only, every dataset bounded

Schema diff — added, changed, removed — diffed in the reader's browser against their last visit

11 · THE STANDARDS

Build on what you already use.

ApiGlow builds on open standards rather than around them — here is exactly what it reads and writes.

OpenAPI 3.0 / 3.1 / 3.2rendered natively, including 3.2's query method and $self
Swagger 2.0converted at load — nothing to run beforehand
JSON Schema 2020-12keywords rendered, not silently dropped
OpenAPI Overlay 1.1applied at load, to fix or enrich a schema you don't own
Arazzo 1.0 / 1.1scenarios import 1.0 and 1.1, export 1.1.0 — the OpenAPI Initiative's workflow format
WCAG 2.2 AAthe target on every interactive path — navigation, try-it, search
12 · THE DEMO

See it live.

Enough describing it — here it is, running. Click through the navigation, send a real request, judge for yourself.

The Petstore demo

Petstore API, mocked in your browser by a service worker — nothing to install, nothing to sign up for.

Live demo

Your own schema

The exact same demo, loaded with your operations — the fastest way to see what ApiGlow makes of your API.

The URL must be reachable from your browser and CORS-readable. Try-it calls go straight from your browser to that API — nothing passes through this site.

Frequently asked questions.

Is it free?

ApiGlow is MIT-licensed and fully open source. There is no paid tier, no cloud version, no account — no business model at all. That’s the point.

Does my schema or my traffic leave the browser?

No. Requests go straight from the reader’s browser to your API. No analytics, no telemetry, and no server of ours — there is nothing to send data to. History, environments and scenarios live in the reader’s own browser storage.

Which OpenAPI versions are supported?

OpenAPI 3.0.x, 3.1.x and 3.2.x natively; Swagger 2.0 is converted at load. OpenAPI Overlay 1.1 is applied at load, and Arazzo workflows are imported (1.0 and 1.1) and exported (1.1.0).

Why can't the try-it console reach my API?

CORS: your API must allow the documentation’s origin. ApiGlow diagnoses the failure in the UI and supports a proxy you host (tryIt.proxyUrl) — it ships none. See Try-it & CORS.

Can I brand it as my own?

Product name, logo, themes and footer links — yes. The small “Powered by” line and the About dialog stay: a CDN install ships no LICENSE file, and that dialog is where the bundled open-source components’ notices live. See the theming guide.

Do I depend on a CDN?

Only if you want to. npm install apiglow gives you the whole dist/ directory: copy it into your static files, point the script tag at your own origin, and nothing leaves it at runtime — no third party in your CSP, and the version pinned in your lockfile. Keep app.js beside its app.css, i18n/ and fonts/: it resolves them relative to itself, which is also why it doesn’t go through a JavaScript bundler. See Installation.

How big is it?

One file: app.js is ~289 KB gzipped as of v0.1.0, plus ~39 KB of CSS; the French UI pack (~24 KB gzipped) downloads only if French is active. Not tiny — but it is the whole product: five runtime dependencies, zero framework, and inside that file an audit engine, an Arazzo runner, a Swagger 2.0 converter, 35 themes and snippets in ten languages.

Which browsers are supported?

The declared floor is Chrome/Edge 111, Firefox 128 and Safari/iOS 16.4 — platform features rated Baseline “widely available”, no polyfills: anything above the floor is feature-detected and degraded instead. The end-to-end suite runs on Chromium, Firefox and WebKit, desktop and mobile emulation; Chromium gates every change, the other engines run on demand.

Is it fast on a large schema?

The performance budgets are enforced in CI against a 12 MB, 1220-operation schema — the frozen GitHub REST API: usable in under a second, no task blocking the page longer than 500 ms, a Cmd+K answer in under 200 ms, deep schema bodies and docs pages in under 400 ms. The budget ceilings may only ever go down — the tooling refuses a raise. The live demo pairs the Petstore with a 1.15 MB, 143-operation second spec — large enough to click around in, without inflicting a 12 MB download on a visitor.

Is it accessible?

ApiGlow targets WCAG 2.2 AA on the interactive paths — navigation, try-it, search — with an axe sweep gating CI, color contrast included, plus a whole-page keyboard walk and a 320-px reflow suite: the sweep runs on both of the app’s own themes and enforces the AA floor like any other rule. Getting there meant making secondary text a color rather than an opacity, since opacity multiplies through a subtree and no ratio computed on a token predicts what actually renders. Two honest limits the project states itself: the contrast promise covers the themes it authors — a ratio fixed on its own palette says nothing about the 35 stock daisyUI themes it also ships, nor about one of yours — and no full screen-reader pass has been done yet.

Can search engines and AI crawlers read the docs?

Out of the box, every route announces itself — per-route titles, a meta description and JSON-LD. For the crawlers that run no JavaScript, apiglow bake writes a static HTML and Markdown mirror of every operation, guide and scenario, plus a sitemap and a served llms.txt — one author-side command, the reader’s install unchanged. And seo: { index: false } keeps internal docs out. See SEO & the bake CLI.

Can I open the docs from a file:// URL?

No. The app is an ES module and fetches its assets, and browsers block both on file://. Any static HTTP(S) server works, including one-liners like python3 -m http.server. See Installation.

Can I hide internal endpoints?

Yes — "x-apiglow-hide": true in the schema, or openapi.hide patterns in the config; hidden operations disappear from the nav, the search and the exports. This is documentation hiding, not security: the browser still downloads the full schema. See Schema control.

One tag. Your docs.

The demo runs on a full 1.15 MB, 143-operation schema — or on yours, pasted above.

<script id="api-doc-config" type="application/json">
{ "openapi": { "url": "https://example.com/openapi.json" } }
</script>
<script src="https://cdn.jsdelivr.net/npm/apiglow@0.1.0/dist/app.js" type="module"></script>