Multiple OpenAPI specs, one portal.

Each entry has a stable id, a title for the selector, and its own schema by URL or inline. Only the active spec is downloaded — an installation with twelve APIs costs the reader one. Every spec gets its own routes (#/s/{id}/…), so deep links land on the right API, and default picks the one shown on arrival.

{
  "openapi": {
    "specs": [
      {
        "id": "payments",
        "title": "Payments API",
        "url": "https://example.com/payments.json"
      },
      {
        "id": "accounts",
        "title": "Accounts API",
        "url": "https://example.com/accounts.yaml",
        "features": { "scenarios": false }
      }
    ],
    "default": "payments"
  }
}

Environments, header memory, request history, OAuth tokens, scenarios, search — all namespaced per spec. A token for the Payments API cannot leak into a request against Accounts; switching specs switches worlds. One consequence to know: the id doubles as the storage prefix, so renaming it is equivalent to resetting that spec’s local data.

The root config is the fallback and nearly every key can be redeclared on an entry — branding, theme, try-it settings, feature switches, environments. The merge rules are few and stated: settings objects merge key by key with the spec winning; lists of named entities merge by identifier; hide and overlays accumulate, root first. Anything a spec declares that cannot apply is flagged by name in the console, never silently dropped.

history is root-only — retention is a browser storage cap, applied to all specs at once. theme.custom is root-only — themes are global chrome, injected once at boot. And scenarios go the other way: declared only on spec entries, because a scenario references operations of one specific spec. Each case is flagged in the console when a config gets it wrong.