Import dbt manifest.json Into Your Pipeline Catalog

Your dbt project already encodes model dependencies. Your orchestrator knows job schedules. Your observability stack knows almost nothing unless you duplicate that graph somewhere else.

Importing dbt manifest.json into DataXPipe is the fastest way to get a searchable catalog with lineage edges and starter checks — without a big-bang migration.

What manifest import produces

When you paste or POST a dbt manifest.json, DataXPipe converts dbt nodes (models, seeds, snapshots) into a catalog payload:

• Sources and targets derived from model IDs
• Lineage edges from depends_on relationships
• Default freshness checks on target tables
• Pipeline metadata with project name, model count, and import provenance

You can register immediately or edit the generated structure into a full YAML spec with connections and schedules.

When to use import vs full YAML

Approach	Best for
manifest import	Existing dbt shops bootstrapping catalog coverage
YAML spec	New pipelines, warehouse connections, custom checks
Both	Import for graph, then add connections and orchestration metadata in YAML

Import gives you discovery and lineage quickly. YAML gives you operations and credentials precisely.

Step-by-step in the app

1. Sign in at app.dataxpipe.com
2. Open Get started → choose Import dbt
3. Paste target/manifest.json from your dbt project
4. Review generated lineage and checks in the wizard
5. Register the pipeline (platform admin) or continue to failure-explain demo

For API access, use the dbt import endpoint documented in the Catalog API reference.

Example: what you get

A project with models stg_orders → mart_orders_daily → mart_executive_kpis becomes lineage edges you can query before changing mart_orders_daily logic. Freshness checks attach to mart targets so silent failures surface when orchestration still reports green.

Enriching after import

Import is a starting point. Production teams typically add:

• Warehouse connections in YAML (connection_ref on sources/targets)
• Owners and schedules matching Airflow or dbt Cloud
• Custom SQL checks (not null on grain, referential integrity)
• Environment tags (dev vs prod) for RBAC

Register updates replace the same pipeline.name without consuming an extra slot on plan limits.

CI recommendation

Keep generating manifest in CI (dbt compile / dbt run artifacts). Optionally POST manifest to import in a staging org to detect lineage drift on every PR — pairs well with spec validation in CI.

Pitfalls

Stale manifest. Import reflects the last compile, not live warehouse state. Regenerate manifest after model renames.

Missing sources. Only dbt nodes appear; external ingestion tables need manual sources in YAML.

Assuming checks are complete. Default freshness is a baseline — add domain checks for revenue, identity, and compliance tables.

Related reading

• dbt and orchestration together
• DataXPipe use cases guide
• Pipeline lineage best practices

Import your manifest today via Get started — most teams have a catalog graph in under five minutes.