An automation is only as reliable as its least reliable upstream source — an HTTP Request node faithfully calls whatever URL you give it, and a source that changes its response shape without warning, rate-limits you into silence, or simply goes down breaks every downstream node exactly as if you'd made the mistake yourself. Picking sources well is unglamorous, invisible work, and it's the difference between an automation that runs for a year and one you're debugging every month.
What actually makes a source reliable
Documented, versioned responses. A source with a /v1/ or /v2/ in its URL, and real documentation of what each field means, is signaling that it treats its response shape as a contract — the kind of thing that changes deliberately, with notice, rather than silently. A source with no version and no docs is telling you the opposite, whether or not anyone at the provider means to.
Reasonable, published rate limits. Every real API rate-limits somehow; the reliable ones publish the number so you can build a polling interval that respects it. An unpublished or unclear limit means you'll find it by hitting it — usually at the worst time, on a workflow running unattended.
A track record of uptime, not just a feature list. A source can have exactly the fields you need and still be unusable if it's down often enough that your automation's "watch" stage silently produces nothing on a regular basis. Check status pages or community reports before building anything real on a source you haven't used before.
A response shape that matches what you actually need. The best-documented, most reliable API in the world is still the wrong choice if getting your one needed field out of its response requires unwinding three levels of nesting a Code node has to fight with every run. Simpler, flatter data is worth some quality trade-off versus a more "complete" but awkward source.
RSS is underrated for exactly this reason
For pure news-watching (as opposed to structured data like prices or scores), RSS remains one of the most reliable choices — not because it's modern, but because it's a mature, unchanging standard that publishers have supported for two decades without dramatic revision. An HTTP Request node reads RSS's XML the same as any JSON response; the practical difference is just parsing (an XML response needs a Code node to extract what you want, where a JSON API often doesn't). For genuinely stable, low-maintenance news watching, that small extra parsing step is often worth trading for a source that's extremely unlikely to break your workflow with an unannounced change.
Testing a source before you build on it
Before wiring a new source into a real automation, three checks with an HTTP Request node's own test-run:
- Call it several times over a day or two, not just once — a source that's fine on your first test but times out or rate-limits on the fifth call reveals itself this way, not on the first look.
- Check what an empty or no-new-items response actually looks like — some sources return an empty array cleanly; others return an error or an unexpected shape when there's genuinely nothing new, which will need handling (an If node checking for this, or a Code node normalizing it).
- Confirm the fields you need are actually always present, not just present in the example you first tested — a field that's sometimes missing is exactly the kind of thing that shows up as a failed downstream binding weeks later, on the one run where it happened to be absent.
Building in resilience where the source can't guarantee it
Even a well-chosen source will occasionally have a bad day. An If node checking for data completeness before anything downstream runs — confirming the fields your template actually needs are present and non-empty — is cheap insurance against a source's off day turning into a broken or blank post rather than just a quiet, harmless skip.