Handling strict hourly API fetches and retries: Using n8n as a middleware cache

Questions
1

Hi everyone,

I’m building a Finnish electricity price-tracking dashboard https://sahkotanaan.fi/. The core of the site relies on pulling regional exchange electricity rates that update exactly once per hour.

Because the national grid’s API has strict rate limits, my frontend can’t fetch from them directly. I am looking to use n8n to act as my backend middleware to handle this.

The ideal workflow I am trying to build is: Schedule Trigger (Top of the hour) -> HTTP Request (National Grid API) -> Code Node (parse and strip out JSON bloat) -> Push clean JSON to Redis/Supabase.

My main issue is that the grid’s API is notoriously flaky exactly at the top of the hour because every energy company in the country is pinging it simultaneously. I often get 502 or 503 timeouts.

I wanted to see how you all handle this kind of time-sensitive architecture in your workflows:

  1. What is your preferred way to build retry logic for a scheduled trigger? If the 14:00 fetch fails, I’d want to retry every 30 seconds for about 5 minutes before throwing a fatal error and routing to a Slack/Discord alert. Do you use the built-in HTTP retry settings, or build a custom loop with the Wait node?
  2. When using n8n as a middleware for a frontend dashboard, do you prefer pushing the final payload to an external database (like Redis), or is there a clever way to use n8n’s webhook nodes to serve the cached data directly to the frontend?

Would love to hear how you structure your error-handling for this kind of setup!

Thanks in advance!

3

Hi @jerry765 , good day!

Very nice!
for this type of content, it’s better to use the Tutorials category; this section is usually for general questions about possible issues or bugs.

4

Hey @jerry765 , this template sounds like exactly the kind of workflow you’re looking for.

FWIW the Help me Build my Workflow category is probably a better home for this question.

5

For the retry logic, the linked template covers it well. On the caching question: n8n does support serving cached data directly from a webhook - use the schedule workflow to fetch and store the result in n8n Variables (Settings > Variables) or workflow static data, then create a separate GET webhook workflow that reads from that store and returns the cached value. This works well for an hourly update pattern like electricity prices. Redis is the better choice if you need sub-second freshness guarantees or want multiple services reading from the same cache simultaneously.