Skippr Docs

Appearance

How Databricks Destination Authentication Works in Skippr ​

June 2026

Databricks destination authentication in Skippr is token-based, but the token has to be authorized across the exact catalog, schema, and optional SQL warehouse the pipeline will use.

Short Answer ​

Databricks destination authentication in Skippr is built around workspace_url, a personal access token, and optionally warehouse_id when you want SQL-warehouse-backed COPY INTO behavior. The docs recommend keeping the token in DATABRICKS_TOKEN, while catalog and schema define the Unity Catalog location the authenticated identity will write to.

The practical auth model is therefore token plus scope. A valid token for https://dbc-xxxxxxxx.cloud.databricks.com is not enough on its own. The same token has to be allowed to write to the selected catalog and schema, and if warehouse_id is set, it must also be able to use that SQL warehouse for query execution.

Why Teams Struggle with This ​

Databricks auth issues rarely come from the token format itself. They usually come from a mismatch between where the token is valid and where the pipeline is trying to write. The docs keep that visible by naming the workspace, warehouse, catalog, and schema separately.

  • The connector authenticates with a personal access token, usually supplied through ${DATABRICKS_TOKEN}.
  • The token must be valid for the exact workspace_url you configure.
  • Unity Catalog permissions on the selected catalog and schema are part of destination authorization.
  • If warehouse_id is used, the same token also needs permission to use that SQL warehouse for COPY INTO or query execution.

How Skippr Handles It ​

Skippr makes the Databricks auth model reviewable because it does not collapse those boundaries into one magical setting. You can see the workspace identity, the token source, the Unity Catalog target, and the optional SQL warehouse in one place.

That is especially helpful once CDC enters the picture. The destination docs and CDC docs line up: the same warehouse identity that uploads files and writes to Unity Catalog also needs to support MERGE into Delta-backed tables with order-token and tombstone protection.

  • Token-based authentication through ${DATABRICKS_TOKEN} and an explicit workspace_url.
  • Clear warehouse scope through catalog, schema, and optional warehouse_id.
  • A documented requirement that the token can write to the target catalog and schema.
  • CDC support through Unity Catalog MERGE with _skippr_order_token and tombstone tables.

What the First Useful Version Looks Like ​

The first useful version is one workspace, one catalog and schema, and no SQL warehouse until you actually need COPY INTO. That keeps the token scope understandable.

If the pipeline will use an existing SQL warehouse, validate that access before rollout. Databricks destination auth is cleanest when the token and execution surface are intentionally paired.