Skip to content
Documentation Prelude Collector

YANG Browser API

Browse YANG catalogs, explore module trees, search nodes, and inspect device deviations through the Prelude Collector REST API.

The YANG Browser API exposes both the Prelude Collector's embedded OpenConfig modules and any device-specific catalogs that have been collected from real hardware. After this first mention, the rest of this page refers to Prelude Collector as "the collector". The browser is the right place to find a path before you put it into a model mapping or a test-path request. This page covers when to use which endpoint, common mistakes, and a worked example. For the full endpoint schema, see the API reference.

When to use this API

  • Discovering YANG paths. Walk the tree of an OpenConfig or device-specific module to find the leaves you actually want to collect.
  • Confirming that a path exists on a real platform. Compare the embedded OpenConfig view to the catalog collected from a specific NetOS and software version.
  • Inspecting deviations. Vendor catalogs frequently mark paths as not-supported or change their type. Read the deviations list before you map a path.
  • Building UI tooling. The lazy-load tree/children endpoint is designed for tree views that expand a node at a time.

Common pitfalls

  • Using the wrong netos/version pair. Path parameters are positional; embedded/openconfig/... for the bundled OpenConfig modules, iosxr/<version>/... for a device-collected catalog.
  • Searching modules that haven't been loaded. Catalogs load on demand. The first request for a netos/version pair may take a moment as the collector parses the modules.
  • Ignoring deviations. A path that exists in OpenConfig may be declared not-supported in the device's YANG catalog — using it in a mapping will silently return empty data.
  • Short search queries. The search endpoint requires at least two characters.

Worked example: find a leaf, confirm it on a device

# 1. List embedded OpenConfig modules.
curl -H "Authorization: Bearer <your-api-token>" \
  https://collector.example.com/api/v1/yang/catalogs/embedded/openconfig/modules

# 2. Search for "admin-status" inside openconfig-interfaces.
curl -H "Authorization: Bearer <your-api-token>" \
  "https://collector.example.com/api/v1/yang/catalogs/embedded/openconfig/modules/openconfig-interfaces/tree/search?query=admin-status"

# 3. Verify the device's catalog reports no deviations on that
#    module. Replace with the netos and version reported in step 1's
#    catalog list.
curl -H "Authorization: Bearer <your-api-token>" \
  https://collector.example.com/api/v1/yang/catalogs/iosxr/7.9.1/modules/openconfig-interfaces/deviations

Bruno: 10 YANG Browser / List embedded modules, 10 YANG Browser / Search node, 10 YANG Browser / Get device deviations

If the deviations list flags the path you intend to use, pick a different one or fall back to a vendor-native module. Once you have a clean path, plug it into a mapping via the Models API and validate end to end with the Protocols test-path endpoint.

Where device catalogs come from

The REST endpoints above are read-only browsing. A device-specific catalog first has to be imported, which you do from the YANG Manager page in the UI. There you pick a device and a collection method — the device's advertised module list is read over gNMI Capabilities or NETCONF list-schemas — and the collector pulls the matching models from a vendor YANG repository.

Branch-aware repository import

Some vendors publish each software release on its own repository branch rather than on a single default branch. Nokia SR Linux is the main example. For these, the collector derives the branch from the device's software version automatically — for example a device running 24.10.1 resolves to the v24.10 branch — so you never have to hand- pick a branch. SR Linux works out of the box; if a device's version can't be parsed, the import falls back to the latest release branch.

Per-vendor-profile repository configuration

Each vendor profile can point at its own YANG repository. On the profile's edit form, under YANG, set:

  • Repository URL — the Git repo holding that OS's YANG models. Leave blank to use the built-in default (where one exists).
  • Repository branch — a fixed branch (main), or a template with {major} / {minor} placeholders (v{major}.{minor}) that the importer expands from each device's version.

If you import for a NetOS that has no repository configured, the YANG Manager sends you to that vendor profile to set one, then retry.

Nearest-release match and augmentation

A device rarely advertises the exact module revisions found in a repo release, so the collector matches the device to the nearest release by version — same major version, closest minor, preferring a release no newer than the device — rather than by raw module overlap alone. Once matched, it resolves YANG augments across the imported modules so vendor extensions attach to their base models; augmented nodes are marked with an aug badge in the tree browser.

Captured vs browsable modules

The catalog list shows two counts per catalog: captured (every YANG file collected for that device) and browsable (the subset that build a standalone tree — the rest are type libraries or deviation- and augment-only modules). Browsable is populated the first time you open a catalog, so it reads 0 until then and is normally lower than the captured total.

Reference

Tree expansion, leaf-listing, and per-module deviation responses are documented in the Bruno collection.

See also

Filtering by: