How to Manage Synapse Destination Credentials in Skippr

July 2026

Keep Synapse destination credentials safe by moving the connection string into SYNAPSE_CONNECTION_STRING, leaving the target schema visible, and limiting the login to the write access the destination actually needs.

Short Answer

Manage Synapse destination credentials in Skippr by keeping schema in config and loading the ADO-style connection_string from ${SYNAPSE_CONNECTION_STRING}. The docs treat the connection string as the secret-bearing field, so it should stay out of skippr.yaml and out of version control.

That setup also needs to match the warehouse behavior. The login in the connection string must be able to reach the Synapse endpoint over TDS and write to the target schema, and when CDC is enabled the same identity supports the documented MERGE-based final-state flow with _skippr_order_token and tombstone tables.

Why Teams Struggle with This

Synapse destination auth usually breaks for familiar reasons: the full connection string is copied into config, then the team still has to untangle schema permissions and endpoint reachability after the secret is already exposed.

• A literal connection string in config exposes the Synapse login and password immediately.
• The target schema should stay visible because it tells reviewers where the load will land.
• A valid login still fails if it cannot create or write objects in the selected schema.
• If the runner cannot reach the Synapse endpoint over the configured TDS connection, rotating the password will not fix the network path.

How Skippr Handles It

Skippr keeps Synapse configuration narrow because the warehouse target and the secret are clearly separated. The visible config shows the schema, and the environment supplies the secret-bearing connection string only at runtime.

That makes it easier to support CDC as well. The same env-backed login that lands the table can run the documented MERGE-based final-state updates without introducing a second credential system.

• Uses connection_string: ${SYNAPSE_CONNECTION_STRING} for the secret-bearing value.
• Keeps the target schema visible and easy to review.
• Supports CDC through Synapse MERGE, order-token columns, and tombstone tables.
• Fits a dedicated login with write access scoped to the landing schema.

What the First Useful Version Looks Like

The first useful version is one Synapse login, one environment variable, and one target schema such as dbo. That proves the connector and the privilege boundary with minimal surface area.

If you later split environments, keep schema targets explicit and rotate connection strings per environment rather than sharing one login across every Synapse workspace.