Integration Design
Checking connector maintenance during vendor selection
Check a reporting connector’s change notices, sync health, repair ownership and historical recovery before choosing a vendor.
Before choosing a reporting connector, verify how the vendor maintains the route and responds when source access, fields or APIs change. A catalogue entry alone does not show how a failure is detected, what it affects or how missing data is recovered.
Specify the exact route
Record the source product and account type, destination, required objects and fields, transfer direction, expected update interval and historical period. Confirm the proposed edition and permissions.
Treat “Connects to Google Ads” as incomplete if a report depends on particular fields and a known reporting deadline. State the required fields and deadline explicitly.
Separate responsibilities: the source provider controls its API and source availability, while the connector vendor maintains its implementation. Your team owns credentials and access decisions, chosen data, metric definitions and the reports built on the output.
Name a contact for each part. This makes it clear who owns each decision or action when something changes.
Request maintenance evidence
Ask the vendor to answer these questions for the proposed connector and plan. For each answer, request a relevant screen, history, release record or written coverage commitment.
- Change notice:Where are field removals, schema changes, authentication changes and API upgrades announced? What notice, if any, is promised?
- Health:Can an owner see the last completed transfer, failures, warnings and affected data? Which alerts are available and who receives them?
- Repair:Who updates credentials, mappings or source permissions? Which faults require supplier work?
- Recovery:Can missed records be loaded after a failure or newly included field? When is a historical resync needed, and what are its usage or cost implications?
- Meaning:How will a report owner discover a source field that still arrives but no longer means the same thing?
A demonstration can show controls in an account, but it cannot establish a response time or coverage that the proposed agreement does not provide. Treat undocumented coverage or commitments as unresolved.
For a Fivetran proposal, inspect the Status tab on the Connection Details page in its dashboard. It shows connection notifications, including schema changes and release phase when a connector is not generally available, alongside sync history, events, warnings and errors.
Fivetran’s Status tab also shows sync frequency, average sync duration over the last 14 days, schema changes over the last 30 days and the time of the last completed sync. Its Sync History chart covers the past hour, day or week, with one day as the default, and shows failed syncs and their errors.
Fivetran’s Schema tab varies by connector: it may be fully customisable, semi-customisable or non-customisable, and it displays schemas, tables and columns. Where supported, the schema configuration can exclude tables, block columns or hash columns; Fivetran says source-schema changes are automatically propagated to connector and destination schemas.
Depending on the connector, including a previously excluded table may trigger a resync. Confirm which required fields are included and how the vendor will assess whether a source change affects a business metric; do not assume every connector offers the same controls or recovery behaviour.
The source API is another dependency. Google says major Google Ads API versions introduce breaking changes and older versions are periodically sunset. Its examples identify v25_0 as a major version and v25_1 as a minor version; major versions can require code changes, while minor versions are backward-compatible.
Ask the vendor to show how it tracks Google Ads API releases, checks the fields you require and informs customers of changes. Google posts sunset notices on its developer blog and updates its deprecation schedule with future sunset dates; ask how the vendor uses both.
Key maintenance checks for reporting connectors
- Sync health visibilityOwner can view last sync, failures, warnings, and affected data; alerts are sent to designated contacts
- Repair responsibilityClear ownership of credential updates, mapping changes, and source permission adjustments
- Recovery capabilityMissed records or new fields can be reloaded; resync timing and cost implications documented
- Semantic change detectionProcess in place to alert report owners when a source field’s meaning changes despite data arrival
Google Ads API versioning and deprecation cycle
- Major version release (e.g. v25_0)
- Introduces breaking changes; requires code updates; not backward-compatible
- Minor version release (e.g. v25_1)
- Backward-compatible; no code changes required
- Sunset notice posted
- Published on Google Developer Blog and deprecation schedule with future sunset dates
Fivetran connector performance metrics (last 14 days)
- Average sync duration
- Not specified – vendor must provide actual value from dashboard
- Last completed sync
- Not specified – vendor must show timestamp from Status tab
- Sync frequency
- Not specified – vendor must confirm interval (e.g. hourly, daily)
- Schema changes (past 30 days)
- Not specified – vendor must show count or list from Schema tab
Give suppliers a change scenario
Use safe sample data. Ask each vendor to show a required field changing and a scheduled transfer failing.
Ask the owner to find the problem in the demonstrated screen or history, identify affected reports, repair the route and check the missing period after recovery. Also ask what happens when a transfer succeeds after the source field’s meaning changes.
Treat the response as evidenced only if the demonstration or records show where the change or failure appears, who owns the repair and how completeness for the affected period is checked. Record any missing or undocumented point as unresolved.
Keep a decision log with the required route, documented coverage, health view, notice route, recovery method, owner and unresolved risk. For a critical report, check that the proposed response fits the reporting deadline.
