Skip to main content
Docs
Feature Requests Onboarding Trust Center Status Page

Community

Expose sync_id in the Sync‑Connection REST API

Answered
Odalis TorresTapia User

The POST /v1/connections/{connection_id}/sync REST API confirms that a sync was triggered, but it does not return the corresponding Fivetran sync_id.

For customers using the REST API with workflow orchestrators (e.g., Airflow), the sync_id is required to reliably track the triggered sync, correlate sync_end and records_modified events, and determine whether data was actually moved. Today, identifying the sync requires indirect workarounds (polling connection status, syncing metadata, and correlating logs by timestamp), which adds complexity and timing dependencies.

Request:
Include the generated sync_id in the sync-connection API response, or expose a lightweight endpoint to retrieve recent sync runs (including sync_id) for core connectors.

This enhancement would simplify orchestration, improve reliability, and reduce operational overhead for API‑driven workflows.

Please sign in to leave a comment.

Comments

2 comments

Date Votes
  • Official comment
    Waldorf Fivetranner

    Hi Odalis, this is Ryan Waldorf, the PM for developer experience at Fivetran.  I've added this request to our long-term backlog which we'll prioritize based on demand (e.g. upvotes here).

    In the meantime, we do have a few workarounds using the Fivetran platform connector, which syncs Fivetran's own logs and metadata into your destination warehouse where you can query them with SQL.

    For completed syncs, the easiest path is the fivetran_platform__audit_table dbt model.  It has one row per table per sync with row counts (inserts, updates, deletes) and a unique_table_sync_key created by hashing the schema_name, connection_id, destination_id, table_name, and write_to_table_start of a sync. This works well once a sync finishes and the model materializes, but won't show in-flight syncs.

    For in-flight syncs, you can query the raw log table directly.  Connections with a recent sync_start event but no corresponding sync_end are still running, and you can sum the records_modified events for that connection to get a running row count.

    You can query the destination warehouse via its SQL API to get this information programmatically.  I'm happy to share SQL examples if that's helpful.   Would this approach be helpful in the meantime?

    Best,
    Ryan

     

  • Odalis TorresTapia User

    Hi Ryan,

    Appreciate the guidance, this is very helpful.

    My use case is to orchestrate syncs using Airflow, where I trigger a SQL connector sync, and once that completes, I trigger the Fivetran metadata connector via the API. The goal is to rely on the metadata/log tables to confirm completion and safely drive downstream processes.

    One key gap for me is the lack of a sync_id when triggering a sync. Having that would let me:

    • Correlate events end-to-end
    • Track a specific sync across log tables
    • Ensure I’m validating the correct execution and not mixing partial or delayed results

    Right now, during testing, I’m seeing that after triggering the metadata sync, the logs are not fully populated immediately, which makes it hard to rely on them for orchestration decisions.

    I’ll go ahead and test your suggested workaround (audit model) to see if it can fit this scenario. In the meantime, if you can share some SQL examples and any best practices to ensure logs are fully propagated before querying, that would be very helpful.

    Thanks again, I’ll test this approach and let you know how it works for my use case.

    Best,
    Odalis