Cloud ETL
Fivetran
Sync history and schema change events via API, plus the _fivetran_synced column in every target.
Fivetran is a managed pipeline, which means the failure modes move rather than disappear. You will not lose rows to a mapping bug you wrote, but you can absolutely have a connector paused, a schema change silently applied, a table excluded from the sync, or a history-mode table growing rows nobody expected.
The compensating strength is that every destination table carries
_fivetran_synced, which makes freshness and reconciliation straightforward
without any additional instrumentation.
What Decim reads from Fivetran
Every item below is read-only, and each is a specific view, endpoint or file rather than a category of access. If something here is unacceptable in your environment, it can be removed from the query catalogue — see the agent for how that works.
| What | From | Why it matters |
|---|---|---|
| Connector state | GET /v1/connectors/{id} | Paused state, sync frequency, last sync and failure |
| Sync history | GET /v1/connectors/{id}/logs | Start, finish and outcome per sync |
| Schema config | GET /v1/connectors/{id}/schemas | Which tables and columns are enabled or blocked |
| Row freshness | _fivetran_synced column | Present in every destination table — freshness for free |
| Soft deletes | _fivetran_deleted column | Rows removed upstream but retained downstream |
| Destination | GET /v1/destinations/{id} | Where the connector writes |
| Transformations | GET /v1/dbt/transformations | dbt runs orchestrated by Fivetran |
Permissions required
Written out in full, because "read-only access" is not a specification. Nothing below grants the ability to write, and row access is requested only on the specific tables you name.
-- Fivetran API: a key/secret pair, used with HTTP Basic auth.
-- Read endpoints only; the agent never calls resync, pause or modify.
-- GET /v1/connectors/{connector_id}
-- GET /v1/connectors/{connector_id}/schemas
-- In the destination warehouse, freshness needs only the metadata column.
GRANT SELECT (_fivetran_synced, _fivetran_deleted, id)
ON raw.transactions TO decim_agent;
-- Which is enough for the check that matters most:
SELECT
max(_fivetran_synced) AS last_sync,
count(*) AS rows_total,
count(*) FILTER (WHERE _fivetran_deleted) AS soft_deleted,
count(*) FILTER (WHERE _fivetran_synced > now() - interval '1 day') AS synced_today
FROM raw.transactions;What it builds
What this source contributes to the pipeline topology and to the evidence available during an investigation:
- Source-to-destination edges per connector, with sync cadence
- Which tables and columns are excluded from the sync — often the real finding
- Schema change events, correlatable against a downstream break
- Freshness per table without any added instrumentation
Nodes learned from a definition are marked declared; nodes observed running are marked observed; nodes both declared and observed are verified. Where two sources disagree, the disagreement is recorded as a drift note rather than resolved silently.
Failure modes it surfaces
What this source is uniquely good at proving — and, just as usefully, at disproving. An investigation that can refute a hypothesis cheaply is worth as much as one that confirms it.
| Failure mode | The signal |
|---|---|
| Connector paused | Paused state with no alert configured |
| Table excluded from sync | Enabled flag false on a table downstream depends on |
| Schema change broke downstream | Column added or retyped, then a dbt model failing |
| Soft deletes misread as live rows | _fivetran_deleted not filtered in a model |
Limits
What this integration cannot tell you. Stated because an investigation that overstates its sources produces confident wrong answers, which is worse than an honest blocked.
- Connector log retention through the API is limited; export to a destination for longer history
- You cannot see inside a connector's extraction logic — it is a managed black box by design
- History-mode tables have entirely different row-count semantics and must not be reconciled the same way
Related integrations
- Snowflake — ACCOUNT_USAGE gives a year of query, copy and task history — including rows loaded and rows rejected.
- dbt — manifest.json is the model graph; run_results.json is what actually happened. Both are artefacts, not APIs.
- BigQuery — INFORMATION_SCHEMA.JOBS gives every statement, its referenced tables and its output row count.
See all integrations, or how the sources are combined into one graph.
Get started
Investigating a Fivetran pipeline?
Bring an incident you already know the answer to. If Decim gets it wrong, that is a more useful demo than one where it doesn't.