agent hallucinated a fivetran connector id that does not exist, sync check failed

TL;DR

Connector ids in Fivetran are opaque generated strings, and an agent asked for one it does not actually know will often produce a confident, well formatted, nonexistent id. Any call with it then fails with a not found style error that looks like a Fivetran problem. List the connectors in the group through the API, match by the connector name and service you intended, and use only an id returned by that list. Never let the agent proceed on an id from memory or from a naming guess.

agent hallucinated a fivetran connector id that does not exist, sync check failed

Use this when

• A sync status check fails saying the connector does not exist or is not found.
• The connector id in the agent's config or message was never copied from the Fivetran UI or an API response.
• The named connector clearly exists in the dashboard under a similar name.

Not for this skill when

• The id came from an API list response and the connector was since deleted. Recreate or repoint deliberately.
• The call fails on authentication. A valid id with a bad credential fails differently; check the error wording.

Steps

1. Capture the failing call: the connector id used, the group it was sent to, and the exact error. Note whether the error is not found versus unauthorised. Verify: the failure is classified before any new id is trusted
2. List connectors for the group through the Fivetran API and search the result by service and schema name for the connector you meant. Note the real id from the response. Verify: the id now comes from the system of record
3. Compare the real id with the invented one and check every place the invented value was written: agent config, a runbook, a ticket, a script default. Note each place to correct. Verify: the bad value is hunted down everywhere it spread
4. Replace it, rerun the sync check, and confirm Fivetran returns the connector state for the real connector. Note the state and the last sync time it reports. Verify: the check works against the real connector
5. Change the workflow so ids are always resolved at run time: the agent lists connectors, matches on name, and refuses to call a per connector endpoint with an unresolved id. Note the guard in the procedure. Verify: an invented id can no longer reach the API

Variant phrasings

fivetran connector not found api wrong connector id

The plain API error phrasing.

fivetran list connectors api get connector id by name

The resolution method searched directly.

Compatibility: Fivetran REST API, connector and group resources. Applies to any agent or script that addresses Fivetran objects by id.

Why it happens

Generated ids are the worst case for a language model: they carry no meaning to memorise, their format is easy to imitate, and a request that names one confidently gives no signal that it was fabricated. The system on the other end cannot help either, because a nonexistent id and a typo look the same to it. Grounding has to happen by construction: resolve names to ids through list endpoints in the same run, and treat any id that did not come from a tool response in this session as unverified.

Edge cases / pitfalls

• Two connectors can share a service and a similar schema name in one group. Match on more than the first hit: destination, schema, and creation context.
• An id copied from a different Fivetran account or a test group is real but wrong. The group is part of the identity, check both.
• Screenshots and old tickets are common sources of stale ids after a connector is recreated. Prefer a live list over any document.
• If an agent wrote the invented id into a shared config, assume other automations picked it up. Search the repo and the runbooks, not just the failing job.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_B70YSrgtPGWh496BIZAbbQ