CATALG — publish catalogs

This page tells you what CATALG does and how it fits into a Fabric network.

Fabric CATALG is the shared catalog publication and distribution service of the Fabric ecosystem. Providers publish their catalogs to CATALG once, and CATALG validates them and pushes them out to every Discovery Service subscribed to that network.

This page tells you what CATALG does and how it fits into a Fabric network. When you are ready to send your first publish request, jump to the Quickstart.

The problem

Without a shared catalog backbone, Fabric networks fragment quickly:

• Every provider publishes through a different mechanism

• Discovery Services maintain stale, inconsistent copies of the same data

• There is no network-wide view of what is live, valid, or active

• Every provider reinvents product definitions independently

The result is duplicated effort, inconsistent search results, and no canonical source of truth.

What CATALG does

CATALG sits between Provider Nodes (the participants that publish catalogs) and Discovery Services (the search layer that consumer applications query). It gives the network:

• One place to publish — every catalog flows through a single validated pipeline

• Automatic distribution — every accepted catalog is pushed to all subscribed Discovery Services within seconds

• Schema-aware validation — catalogs are checked against the Fabric v2.0 schema and any domain overlays before acceptance

• Network-wide templates — a network can publish canonical resource definitions that providers extend, ensuring data consistency across the network

• Granular visibility control — publishers can restrict delivery to specific network participants

CATALG is not a query engine. It is the source of truth for what is published. Consumer applications never call CATALG directly — they query a Discovery Service, which keeps its data current by subscribing to CATALG.

High-Level Architecture

How it works end-to-end

The full lifecycle — from a Discovery Service setting up its subscription, through a network publishing master templates, to a provider publishing a real catalog and a consumer discovering it:

Key points:

• Subscription is synchronous — CATALG returns subscriptionId and status: ACTIVE directly in the 200 OK response

• Publish ACK is synchronous — returned immediately once the request passes authorization and schema checks

• on_publish is asynchronous — notifies the publisher of the per-catalog result (ACCEPTED / REJECTED / PARTIAL)

• catalog/push is synchronous — CATALG POSTs to each matching Discovery Service and receives an immediate ACK or NACK; delivered only when the catalog is ACCEPTED or PARTIAL

• on_discover is asynchronous — Discovery Service calls the Consumer Node's bapUri with matching results

Where you fit

Example use case

A multi-brand EV charging network wants to list all its charging stations nationwide. The network facilitator first publishes a master (template) catalog defining canonical charging resource schemas — connector types, power levels, tariff structures.

Each charging operator then publishes a REGULAR catalog extending the master templates, adding their specific stations, live availability, and pricing. CATALG validates every submission and automatically pushes accepted catalogs to all subscribed Discovery Services.

One such Discovery Service — Fabric DISCOVR — makes the data available for discovery. A mobility app queries DISCOVR for "CCS2 chargers above 50 kW near Bangalore" and gets real-time results from multiple operators in a single response.

Next: Quickstart — Publish Your First Catalog →

The Fabric capability: Cataloguing

CATALG realises the Fabric Cataloguing capability — a canonical surface for publishing offerings (items, prices, providers, locations, terms) to the entire network in one motion. Catalogues live in Fabric; transactions happen off it.

What it gives you

• Publish once — one source of truth, network-wide reach.

• Provider identity — every offering tied to a Registry identity.

• Structured schemas — typed items, prices, terms, quantities, geos.

• Versioning — offerings change without breaking subscribers.

• Multi-network publishing — the same offering can appear in multiple networks via policy.

Where it sits — a service NFH runs (the cataloguing surface where providers publish) plus the protocol NFH defines (the schemas for offerings, items, and providers).

Standards alignment: Beckn Protocol v2 catalogue schemas · JSON-LD.