> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# CDP BI-tool connector catalog: pull Orbit data into Tableau, Power BI, Looker, Superset, or Metabase

> Discover the supported BI-tool connectors and generate a per-tool connection profile — driver, connection fields, and schema-qualified datasets — so your analytics team reads Orbit's warehouse export directly from their BI single-pane-of-glass.

# CDP BI-tool connectors

The **BI-tool connector catalog** is the answer to "how do our analysts pull Orbit data into the BI tool they already use?" Reverse-ETL destinations move CDP data *out* to martech; the warehouse export loads contacts, events, audiences, and profile traits into a warehouse you own. This catalog is the other half: it tells a BI tool how to read those tables, without CSV exports or hand-written SQL.

## 1. Pull into BI vs push via reverse ETL

Orbit's export families split along two directions:

* **Reverse-ETL destinations (push)** — Orbit writes your CDP entities into a destination (a warehouse, a martech endpoint, a webhook). Wire these when you fan data outward on a schedule.
* **BI-tool connectors (pull)** — your BI tool connects natively to the warehouse the reverse-ETL export already loads (BigQuery, Snowflake, Redshift, Postgres, or Databricks) and reads the curated datasets from there. No new pipeline, no new export — the warehouse export hub is the substrate, and the connector catalog is metadata over it.

Because the BI tool connects to *your* warehouse with *your* credentials, Orbit never sits in the query path and never proxies warehouse access. The catalog supplies the connection profile; the credentials stay tenant-owned.

For the warehouse export itself, start with the
[reverse-ETL warehouse exports guide](/guides/reverse-etl-warehouse-exports)
or the [CDP reverse ETL operator walkthrough](/guides/cdp-reverse-etl-and-warehouse-exports).

## 2. Catalog listing

List the supported connectors:

```bash theme={null}
curl https://api.orbit.devotel.io/api/v1/cdp/bi-connectors \
  -H "X-API-Key: dv_live_sk_your_key_here"
```

Filter the list with three optional query parameters:

* `?status=` — `ga`, `beta`, or `coming_soon`.
* `?warehouse=` — restrict to tools that connect to one warehouse (`bigquery`, `snowflake`, `redshift`, `postgres`, `databricks`).
* `?search=` — a case-insensitive substring over the tool name, vendor, or description (≤100 characters).

The response returns the filtered connectors plus three discovery blocks:

* `statuses` — per-status facet counts over the full catalog (the filter sidebar).
* `warehouses` — the live warehouse list with each warehouse's driver name.
* `datasets` — the curated analytics datasets (`contacts`, `events`, `audiences`, and `campaigns`) with their labels.

A bad `status` or `warehouse` value returns a `400` rather than silently an empty list.

## 3. Per-tool metadata

Fetch one tool's full catalog entry before you wire it:

```bash theme={null}
curl https://api.orbit.devotel.io/api/v1/cdp/bi-connectors/tableau \
  -H "X-API-Key: dv_live_sk_your_key_here"
```

The response carries the vendor, the supported warehouses, the connector status, and the tool's own documentation URL. An unknown `tool_id` returns `404`.

## 4. Connection-profile generation

Generate the exact connection shape an analyst follows to point the tool at your warehouse — driver, connection fields, schema-qualified datasets, and ordered setup steps:

```bash theme={null}
curl -X POST https://api.orbit.devotel.io/api/v1/cdp/bi-connectors/tableau/connection-profile \
  -H "X-API-Key: dv_live_sk_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "warehouse": "snowflake",
    "schema": "orbit_cdp",
    "dataset_keys": ["contacts", "events"]
  }'
```

Request body:

* `warehouse` (required) — a live Orbit warehouse: `bigquery`, `snowflake`, `redshift`, `postgres`, or `databricks`.
* `schema` (optional) — the schema the export writes to; defaults to `orbit_cdp`.
* `dataset_keys` (optional) — restrict the profile to a subset of the curated datasets (≤20 keys); omit to include all four.

```json theme={null}
{
  "data": {
    "tool_id": "tableau",
    "status": "ga",
    "connection_available": true,
    "profile": {
      "tool": { "id": "tableau", "name": "Tableau" },
      "warehouse": {
        "id": "snowflake",
        "name": "Snowflake",
        "driver": "Snowflake (native connector / ODBC)"
      },
      "schema": "orbit_cdp",
      "connectionFields": [
        { "key": "account", "label": "Account identifier", "help": "e.g. xy12345.eu-west-1." },
        { "key": "warehouse", "label": "Virtual warehouse", "help": "Compute warehouse used to run BI queries." },
        { "key": "database", "label": "Database", "help": "The database Orbit reverse-ETL writes to." },
        { "key": "schema", "label": "Schema", "help": "The schema holding the Orbit tables." }
      ],
      "datasets": [
        { "key": "contacts", "label": "Contacts", "qualifiedTable": "orbit_cdp.orbit_profiles", "description": "..." },
        { "key": "events", "label": "Events", "qualifiedTable": "orbit_cdp.orbit_events", "description": "..." }
      ],
      "steps": [
        "In Tableau, add a new data source using the Snowflake connector (Snowflake (native connector / ODBC)).",
        "Point it at the Snowflake where Orbit's reverse-ETL export runs and select the 'orbit_cdp' schema.",
        "Add the Orbit tables you need: orbit_cdp.orbit_profiles, orbit_cdp.orbit_events.",
        "Use your own warehouse credentials — Orbit does not proxy warehouse access.",
        "Build dashboards directly on the tables; the reverse-ETL export keeps them up to date on its schedule."
      ],
      "notes": [
        "These tables are populated by Orbit's reverse-ETL warehouse export — enable that warehouse destination first.",
        "Refresh cadence in your BI tool should match the reverse-ETL export schedule to avoid stale rows."
      ]
    }
  }
}
```

Three properties carry the contract:

* **`datasets` are schema-qualified.** Each entry names the fully qualified table (`orbit_cdp.orbit_profiles` for contacts, `orbit_cdp.orbit_events` for events, `orbit_cdp.orbit_audiences` for audiences). Campaign engagement reads from the events table filtered on the `campaign_id` property — it is a view over the event stream, not a separately loaded table, so the catalog describes it as such.
* **No secrets, ever.** `connectionFields` are labelled placeholders (account, host, database, schema — whatever the warehouse's driver asks for), and the setup steps remind the analyst to authenticate with their own credentials. Orbit never proxies warehouse access, so the profile is safe to paste into a ticket or a runbook.
* **Honest maturity.** Every response echoes `tool_id`, `status`, and `connection_available`. A `coming_soon` connector still returns a profile for discovery, but the dashboard renders a request-access action rather than a connect button.

Error shape: `404` for an unknown tool; `400` for a body parse failure; `400` field error when the tool does not natively connect to the chosen warehouse, the schema name is not a valid SQL identifier, or a requested dataset key is unknown. The generation route is rate-limited tighter than the reads (30/min vs 60/min) because it builds a payload rather than serving a directory.

## 5. Auth and roles

All three routes require either a Clerk session or an API key, and a role of **owner, admin, or developer** — the same gate as the sibling destination catalog. The payload is static product metadata (no tenant or customer data, no secrets), so no additional scope is required. Reads run at 60 requests per minute per tenant; the profile-generation POST runs at 30 per minute.

## 6. Supported tools

Full-detail metadata plus connection-profile generation are live for:

| Tool | Vendor | Warehouses |
| - | - | - |
| **Tableau** | Salesforce | BigQuery, Snowflake, Redshift, Postgres, Databricks |
| **Microsoft Power BI** | Microsoft | All five warehouses |
| **Looker** | Google | All five warehouses |
| **Apache Superset** | Apache | All five warehouses |
| **Metabase** | Metabase | All five warehouses |

The catalog also carries **Sigma**, **Mode**, and **Amazon QuickSight** — QuickSight pairs with Redshift natively — and a tool enters `ga` only when it natively connects to at least one warehouse Orbit's export actually loads, so a GA badge always maps to a real, serviceable connection.

## Related guides

* [Reverse-ETL warehouse exports](/guides/reverse-etl-warehouse-exports) — set up the BigQuery, Snowflake, or Redshift destination that populates the tables your BI tool reads.
* [CDP reverse ETL operator walkthrough](/guides/cdp-reverse-etl-and-warehouse-exports) — the destinations panel, warehouse editor, and sync-run history behind the export.
* [Destination and connector catalogs](/guides/cdp-connectors-catalogs) — the outbound (push) mirror of this catalog.
* [CDP source and destinations console](/guides/cdp-source-and-destinations) — the integrations page where warehouses are configured.
* [Insights hub orientation](/insights/overview) — the dashboard's native analytics surfaces when you do not need an external BI tool.