HTTP and MongoDB: Poll-and-Diff Change Detector Template

A scheduled workflow that polls any REST API, compares the fresh snapshot against the last one stored in MongoDB, and acts only on what actually changed.

What It Builds

This Spojit template runs on a Schedule trigger. On each tick a Connector node on the http connector fetches the current snapshot from an external API with http-get, a Connector node on the mongodb connector reads the previously saved snapshot with find-documents, and a diff is computed with the json connector's diff tool. A Condition node skips the rest of the run when nothing changed; otherwise the workflow reacts to the delta and writes the new snapshot back with update-documents so the next run has a fresh baseline. This is the classic change-detection pattern for sources that have no webhook.

The Prompt

Paste this into Miraxa, the intelligent layer across your automation, and it builds the workflow, connecting the tools for you:

Build a workflow on a Schedule trigger that runs every 15 minutes. Use the http connector to GET the current data from https://api.example.com/v1/items, then use the mongodb connector to find the last saved snapshot for this source in the "snapshots" collection. Use the json connector to diff the new response against the saved snapshot, and add a Condition node that stops the run when there are no differences. When something changed, send the changed items to a Slack channel, then use the mongodb connector to upsert the new snapshot back into the "snapshots" collection so the next run compares against it.

Connectors Used

  • Schedule trigger - fires the poll on a cron interval and IANA timezone, output {{ scheduledAt }}.
  • http - http-get pulls the current snapshot from the external REST API.
  • mongodb - find-documents reads the last snapshot and update-documents writes the new one back (upsert).
  • json - diff compares the new payload against the stored one so you act only on the delta.
  • slack - send-message posts the changes (swap for any reaction you want).

Customize It

Change the cron interval in the prompt to match how fresh the data must be, and point the URL at your own API (add the auth header your API needs, such as Authorization). Swap the MongoDB collection name and the match key your snapshot is stored under so multiple sources can share one collection. The reaction is the most flexible knob: instead of a Slack message you can write the changed records to another mongodb collection, call back out with http-post, or hand the delta to an Agent-mode Connector node to summarize what changed before notifying anyone.

Tips

  • Keep the snapshot you store in MongoDB minimal: persist only the fields you compare on, so the diff stays meaningful and the stored document stays small.
  • Use Direct mode for the http-get, find-documents, and update-documents calls so the run is deterministic and costs no AI credits; reserve Agent mode for interpreting the delta if you need it.
  • On the very first run there is no prior snapshot, so the whole response reads as new. Seed the MongoDB collection once, or let the first run write the baseline and treat its output as expected.

Common Pitfalls

  • If the API returns fields in a different order each call, the diff can report false changes. Pick or sort the fields you care about with the json connector before diffing.
  • Forgetting to write the new snapshot back leaves every run comparing against the same stale baseline, so the workflow keeps firing on the same change. Make sure the update-documents step is on the path that runs after a change is detected.
  • A very chatty schedule can outrun the source API's rate limits. Widen the cron interval before adding retries.

Related

Did this answer your question? Thanks for the feedback There was a problem submitting your feedback. Please try again later.