Integrations
A central credential store for external services. Define a credential once, then reference it from any scheduled job or notification rule without re-entering secrets.
Overview
The Integrations page lives under Settings and acts as a "define once, reference many" vault for outbound credentials. Instead of pasting the same service principal or API key into every job, you create a named credential here and select it wherever it is needed.
Key benefits:
- Single point of rotation - when a secret changes, update it in one place and every job that references it picks up the new value automatically
- Test before you trust - every credential has a one-click Test button that validates connectivity before you wire it into a production schedule
- Provider-aware layout - credentials are grouped by type with a summary chip band so you can see at a glance how many of each provider you have configured
Supported Providers
Power BI
Refresh Power BI semantic models automatically after a dbt run completes.
| Field | Description |
|---|---|
| Name | A friendly label (e.g. "Analytics Refresh") |
| Tenant ID | Your Entra (Azure AD) tenant identifier |
| Client ID | The application (client) ID of the service principal |
| Client Secret | The corresponding secret value (write-only, never displayed after save) |
Once saved, the credential appears in the Post-Run Actions section of any scheduled job. Select one or more workspace : model pairs and the platform will trigger a refresh whenever the job succeeds.
API Endpoint
Call any authenticated HTTP endpoint when a job reaches a terminal state. Useful for triggering downstream pipelines, webhooks, or custom automations.
| Field | Description |
|---|---|
| Name | A friendly label (e.g. "Pipeline Webhook") |
| Base URL | The endpoint to call (e.g. https://api.example.com/hook) |
| Auth type | Bearer token, API key (header or query), or Basic auth |
| Auth value | The token or key (write-only, never displayed after save) |
| Max retries | Number of automatic retries on transient failures (429 / 5xx), 0 to 10 |
| Backoff strategy | How the delay grows between retries: exponential (recommended) or fixed |
| Backoff (seconds) | Base delay between retry attempts, 0 to 300 |
| Timeout (seconds) | Per-request timeout for the outbound call, 1 to 300 |
The platform sends a POST request with the job run context in the body.
Retry and timeout policy:
- Exponential backoff (default) grows the wait after each failed attempt, giving a struggling endpoint room to recover. Fixed delay waits the same amount between every retry.
- The per-request timeout applies to both the connection and the response, so a slow or hung endpoint can't stall a job run indefinitely.
- All retry and timeout inputs are clamped to the allowed ranges shown above, both in the editor and on the server, so a credential can never be saved with out-of-bounds values.
PagerDuty
Trigger or resolve PagerDuty incidents from scheduled job alerts using the Events API v2.
| Field | Description |
|---|---|
| Name | A friendly label (e.g. "On-Call Alerts") |
| Routing Key | The Events API v2 integration (routing) key (write-only, never displayed after save) |
Once configured, you can reference this credential from any scheduled job's notification settings. When a job fails, an incident is triggered; when it recovers, the incident is automatically resolved.
Creating a Credential
- Go to Settings - Integrations
- Click + New Integration (or click a provider in the "What you can connect" catalog to pre-select the type)
- Fill in the required fields for the selected provider
- Click Test to validate connectivity
- Click Save
The credential is now available to reference from any scheduled job's post-run actions or notification settings.
Editing and Deleting
- Click the pencil icon on any credential card to open the edit drawer. Secret fields show as masked; only supply a new value if you want to replace the existing one
- Click the trash icon to delete. A confirmation dialog prevents accidental removal. If the credential is referenced by active jobs, those references will need to be updated
Testing Credentials
Every credential card has a Test button that performs a live connectivity check:
- Power BI - authenticates with your Entra tenant and verifies the service principal has access
- API Endpoint - sends a test request to the base URL and confirms a successful response
- PagerDuty - validates the routing key against the Events API v2
A green checkmark confirms the credential is working. If the test fails, you will see an error message describing the issue.
How Credentials Are Used
Credentials flow into two areas of the platform:
Post-Run Actions (Scheduling)
In the schedule wizard, the "When this finishes" section lets you attach actions that fire when a job reaches a terminal state:
- Power BI Refresh - select a Power BI credential, then pick one or more workspace : model pairs to refresh
- API Endpoint - select an API Endpoint credential; the platform POSTs job context to your URL
See Job Scheduling - Post-Run Actions for details.
Job Notifications (PagerDuty)
In the schedule wizard's notify step, select a PagerDuty credential to attach incident alerting to the job. Failed runs trigger an incident; successful recovery resolves it.
See Notifications for all available channels.
How It Compares
| Capability | dbdeux Integrations | Manual secrets in CI | Third-party orchestrators |
|---|---|---|---|
| Central credential store | Yes - define once, reference everywhere | No - duplicated across pipelines | Varies - some have vault integrations |
| One-click test | Yes - per credential | No | Rarely |
| Secret rotation | Single edit propagates | Update every pipeline | Depends on vault setup |
| Provider-aware UI | Typed forms per provider | Generic env vars | Generic key-value |
| Post-run triggers | Built-in Power BI + HTTP + PagerDuty | Custom scripts | Plugin-dependent |