Many thanks for the follow up.

That explains why the sync ID isn’t available when the request returns. We don’t need the sync to start synchronously, or its ID immediately. What we need is a reliable way to associate an accepted API request with the sync that eventually results from it.

Our application lets administrators request a refresh of data via our application which uses the Fivetran API. Fivetran also runs scheduled syncs, and manual syncs outside our application remain allowed although only in the event of a problem with our application triggering it.

We need to:

Tell the administrator whether their requested refresh is queued, running, completed, or failed.
Distinguish an application-requested sync from a scheduled sync or another manual trigger.
Track the resulting sync through completion and associate our downstream data load with it.
Matching the next sync by timestamp isn’t reliable: a scheduled sync or another manual request could occur while ours is queued. An API timeout also leaves us uncertain whether the request was accepted, so simply retrying could submit another request.

Is there an existing way to correlate the trigger with the eventual sync—for example, a queued-operation ID returned by the endpoint, a client-supplied correlation token carried into the sync history or webhook, or an audit record that maps the trigger to the resulting sync ID?

If requests can be combined with an already queued or running sync, knowing which sync satisfies the request would also work. We don’t require a separate sync for every request; we need an unambiguous association.

We’ve investigated sync history, webhooks, and Platform logs, but haven’t found a documented request-to-sync link. Timing and API-key identity help narrow the possibilities, but don’t uniquely identify a request.

Is there a supported workaround that provides that association while leaving scheduled syncs and other manual triggers available?