Chain a Vendor API Changelog Watcher That Drafts Impact Notes

What This Builds

Upstream vendor APIs change without much notice, and for a lot of teams the first sign is a broken pipeline at 6am. This build watches a vendor's changelog or status page on a schedule, and when something changes, sends it through an AI step that drafts a note on what might be affected in your pipelines. It converts a "we found out when it broke" problem into an early warning, for the vendors you do not have time to check manually every week.

Prerequisites

• A rough mental map of which pipelines depend on which vendor APIs (you do not need this formally documented, just enough to know which vendors are worth watching)
• {{tool:Make.plan}} Make account ({{tool:Make.price}}): Sign up - a scheduled scenario with an RSS/HTTP module and an AI module
• A ChatGPT API key for the drafting step, billed per token with a spend cap you set
• Total ongoing cost: your Make plan plus small metered API usage, since this runs on a schedule (hourly or daily) rather than continuously

The Concept

This is a smoke detector, not a fire suppression system. It does not fix a broken pipeline. It notices when a vendor changed something before you find out the hard way, and it gives you a head start. The AI step's job is narrow: read a changelog entry and guess, in plain language, whether it sounds like it touches the kind of thing your pipelines depend on (an endpoint, a field, an auth method). You still decide whether it actually matters.

Data Sensitivity Note

This workflow only touches public vendor changelog and status page content, not your own data, which keeps it lower risk than most Level 4 builds. The caution here runs the other direction: do not paste your internal pipeline code, credentials, or connection strings into the AI drafting step to give it "more context." Keep the context high-level (vendor name, which of your pipelines use it, in plain English) and let the AI reason about likely impact from that, not from your actual source.

Build It Step by Step

Part 1: Watch the source

1. In Make, create a scenario with an RSS module if the vendor publishes a changelog or status page as an RSS feed (many do, even if it is not advertised), or an HTTP > Make a request module on a Schedule trigger (check hourly or daily depending on how fast you need to know) that fetches the changelog page and compares it against the last fetched version.
2. If using the HTTP approach, add a Data Store module to save the last-seen content hash, so the scenario can detect "this changed since last time" instead of re-processing the same page every run.
3. Add a Filter step so the scenario only proceeds past this point when something actually changed, not on every scheduled tick.

Part 2: Draft the impact note

1. Add an AI module (ChatGPT connector, or an HTTP module to the API directly) with this prompt, filling in your own list of vendor-dependent pipelines:

You are drafting an early-warning note for a data engineering team about a vendor API or platform change. You will receive: the vendor name, the new changelog or status page text, and a short list of this team's pipelines that depend on that vendor (in plain language, not code). Write a note with two parts: What Changed (1-2 sentences summarizing the changelog entry in plain language), Possible Impact (1-3 bullets on which of the listed pipelines seem worth checking, stated as "worth checking" not "will break," since you cannot see the actual pipeline code). If the changelog entry does not seem relevant to any listed pipeline, say so plainly instead of forcing a connection.

1. Keep the "list of pipelines that depend on this vendor" input to plain descriptions ("nightly orders sync pulls from the Stripe API") rather than pasting actual pipeline code or connection details into the prompt.

Part 3: Deliver

1. Add a Slack module to post the note to a channel your team actually watches, not a channel that becomes another unread badge.
2. Include the raw changelog link in the message so a reader can go straight to the source instead of trusting the summary alone.

Real Example: A payments vendor deprecates an API version

Setup: A daily Make scenario watches a payments vendor's changelog RSS feed. It detects a new entry: "API v2 will be deprecated in 90 days, migrate to v3."

Input: Changelog text plus the team's pipeline list, which includes "nightly settlement sync pulls transaction records from [vendor]'s API."

Output: A Slack note: What Changed explains the v2 deprecation and the 90-day window in plain language. Possible Impact flags the nightly settlement sync as worth checking against the vendor's migration guide, and notes the changelog entry did not mention webhooks, so anything relying on the vendor's webhook events is probably unaffected, stated as a guess rather than a fact.

Time saved: Surfaces a 90-day deprecation window on day one instead of week six, when someone happens to notice it browsing the vendor's docs for an unrelated reason.

What to Do When It Breaks

• Scenario runs for months and then silently stops firing after a vendor changes their page structure and the RSS feed breaks → This is the failure you will not notice, because "no new notes" looks identical to "nothing changed." Add a Make error notification on the scenario, and separately, once a quarter, manually check that the watched vendor's changelog still matches what the scenario's Data Store last recorded.
• AI note forces a connection between an unrelated changelog entry and your pipelines → Tighten the prompt's instruction to say "not relevant" plainly when nothing matches, and periodically skim the last month of notes for pattern of false positives, adjusting the pipeline-list descriptions to be more specific if the AI keeps overreaching.
• Vendor changes their changelog page format and the HTTP fetch starts pulling garbled or empty content → Check the scenario's raw fetch output first (not the AI output) whenever a note looks off. A parsing break upstream will make the AI draft a confused or empty note, which can look like the AI is the problem when the real issue is the fetch step.
• Too many low-value notes train the team to ignore the channel → If most notes turn out to be "not relevant," narrow the watch list to fewer, higher-stakes vendors rather than watching everything.

Variations

• Simpler version: Skip the AI drafting step and just post raw changelog diffs to Slack. Faster to build, but you lose the "is this even relevant to us" filtering.
• Extended version: Add a second AI step that checks the note against your actual pipeline code (via a code-search API or a GitHub Copilot-assisted grep) for a more concrete "yes, this touches load_transactions.py" answer instead of a plain-language guess.

What to Do Next

• This week: Pick your two or three highest-risk vendor dependencies (the ones where a silent break costs the most) and set up watchers for those first.
• This month: Refine the pipeline-list descriptions fed into the prompt based on which notes turned out useful versus noisy.
• Advanced: Route any note flagged high impact into the "Chain a New Data Source Onboarding Workflow" review queue if the vendor change is big enough to warrant re-onboarding that source.

Advanced guide for Data Engineer professionals. These techniques use more sophisticated AI features that may require paid subscriptions.