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

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!

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.

مرحباً @jerry765 ، هذا النموذج يبدو أنه بالضبط سير العمل الذي تبحث عنه.

للمرجع، فئة ساعدني في بناء سير عملي ستكون على الأرجح موطناً أفضل لهذا السؤال.

بخصوص منطق إعادة المحاولة، يغطي النموذج المرتبط ذلك بشكل جيد. أما بشأن سؤال التخزين المؤقت: n8n يدعم بالفعل تقديم البيانات المخزنة مؤقتاً مباشرة من webhook - استخدم سير العمل المجدول لجلب وتخزين النتيجة في متغيرات n8n (Settings > Variables) أو في البيانات الثابتة لسير العمل، ثم أنشئ سير عمل webhook منفصل للحصول على البيانات يقرأ من هذا المخزن ويعيد القيمة المخزنة مؤقتاً. هذا يعمل بشكل جيد لنمط التحديث كل ساعة مثل أسعار الكهرباء. Redis هو الخيار الأفضل إذا كنت تحتاج إلى ضمانات حداثة أقل من ثانية واحدة أو تريد خدمات متعددة تقرأ من نفس المخزن المؤقت في نفس الوقت.