How I Built an OutboundSync API Monitor in Make

I’d heard of APIs before but had never actually used one—and honestly, I didn’t really understand how they worked. When I started this project, I assumed building something with an API would be difficult and land squarely on the engineering side.

Once I broke it down into small steps, it clicked: at a basic level, an API is just a way of asking whether a certain part of a system is working—and getting a straight answer back.

I wanted something useful for OutboundSync, so I built a Make scenario that watches one of our public API endpoints every hour, logs each check to Google Sheets, and Slack-alerts only when something looks wrong. No API key, no write calls—just a read against a public surface we already expose. Here’s how each piece works.

The overall workflow

The whole thing is four modules wired in a line: an HTTP request, a Google Sheets row, an If/Else check, and a Slack message. The main path runs HTTP → Google Sheets → If/Else. From there it branches: if the status code is anything other than 200, it sends a Slack alert; if it’s 200, it does nothing. The scenario runs automatically, once every hour.

Step 1: HTTP — make the request

The first module sends a GET to an OutboundSync public endpoint. GET means “read”—it asks for information without changing anything, so it’s safe to run on a schedule. For this build I pointed it at https://outboundsync.com/content-index.json, a public JSON map of the OutboundSync site (no auth required). The same Make pattern works for other OutboundSync public endpoints you want to watch—swap the URL and keep the rest of the scenario.

Step 2: Google Sheets — log the response

Every run is logged as a new row in Google Sheets, so we keep a full history of every check—not just the latest result. That history is what makes it easy to spot exactly when something stopped working. Each row captures:

• Checked At — when the automation ran.
• Last Updated — the timestamp returned by the endpoint.
• Status Code — 200 means the request was successful.
• Source — the OutboundSync endpoint that was checked.
• Content-Type — the type of data returned (JSON, in this case).
• Results — an easy-to-read summary of the response.
• Site Last Updated — the same timestamp as Last Updated, formatted cleaner.

One honest caveat: this particular endpoint stamps Last Updated with the current time on every request—so it ends up matching Checked At rather than acting as a real “content changed” signal. This is a health monitor (“is the OutboundSync public endpoint up?”), not a change detector (“did we publish something new?”). For true change-detection, we’d track something more stable, like the page count in the JSON.

Step 3: If/Else — check the status code

This filter checks the status code. If the status code is not 200, the workflow follows the path to Slack. If it is 200, it does nothing—no noise on a normal day.

Step 4: Slack — send an alert when needed

If the OutboundSync endpoint doesn’t return a 200, this module posts to our Slack channel so we know something needs attention. The alert includes the status code, the source URL, and the time—enough to start looking into it right away.

What I learned

• OutboundSync’s public endpoints are approachable. You don’t need a key or a custom client to start—just a URL and a GET.
• Breaking a big problem into small steps makes it far easier to solve.
• Logging every check gives you a trail when something fails, not only the latest status.
• Automation is about the logic before you build—not about writing complex code.

What’s next

This is a starting pattern. We can point the same Make scenario at more OutboundSync public endpoints, tighten the Slack message, or chart the Google Sheets history over time.

Even this small workflow already helps: we see whether the public surface is answering, and we get pinged the moment it isn’t.