---
id: "VOLT-HOME-WP-093"
title: "Polling or webhooks: which gives n8n the more reliable auction signal?"
slug: "polling-or-webhooks-which-gives-n8n-the-more-reliable-auction-signal"
description: "Production notification receipts support webhook-first n8n automation with polling as a reconciliation path, not a competing duplicate trigger."
published: "2026-08-30"
cluster: "Reliable automation and machine-readable energy evidence"
status: "measured"
evidence: "/research-data/home-papers/polling-or-webhooks-which-gives-n8n-the-more-reliable-auction-signal.json"
figure: "/research-media/home-papers/polling-or-webhooks-which-gives-n8n-the-more-reliable-auction-signal.webp"
figure_alt: "Chart for Polling or webhooks: which gives n8n the more reliable auction signal?: median webhook latency advantage over 30-second polling, shown as webhook, 30s polling."
source_ids:
  - "google-article"
  - "google-structured-data"
  - "google-scaled-content"
  - "entsoe-sdac"
  - "volt-architecture"
peer_reviewed: false
---

## Abstract

n8n can discover a completed day-ahead auction curve through a pushed webhook or by repeatedly polling an API. The frozen evidence compares notification latency with a declared 30-second polling interval. Across 2,141 production-origin auction publication receipts, the evidence reports a median webhook latency advantage of 30.0 seconds. The underlying analysis computes that headline as 30 seconds minus the median observed detection-to-notification delay. The regenerated public artifact reports no uncertainty interval for this estimand.

Latency is not the same as reliability. The receipts show how quickly successful notifications followed complete-curve detection; they do not expose webhook delivery-failure frequency, n8n uptime, or polling-request failures. The defensible architecture is therefore webhook-first with polling reconciliation. A webhook starts the workflow quickly. A slower poll checks whether any complete publication was missed. Both paths converge on one idempotent event identity, and neither is permitted to act on an incomplete, stale, or mismatched curve. Production receipts ground the latency comparison. Suggested dropped-webhook, duplicate-delivery, and delayed-poll scenarios are deterministic fault injections for future integration testing, not tests claimed as measured here. The result supports a hybrid operational pattern, not a claim that webhooks alone are universally more reliable.

## Plain-language answer

Use webhooks for speed and polling for recovery. In the measured receipts, successful webhook notifications arrived roughly a polling cycle sooner than a workflow that checks only every 30 seconds. The artifact rounds the reported advantage to 30.0 seconds across 2,141 receipts.

Do not wire the webhook and poll into separate actions. They may both discover the same auction curve. Instead, send both into one n8n subworkflow that validates the zone, delivery date, completeness, publication identity, and freshness, then attempts to acquire an idempotency key. Only the first valid observation may start the household action. Later observations should update audit state or confirm reconciliation without repeating the command.

If the webhook never arrives, polling can recover. If polling is delayed, the webhook provides the fast path. If both are unavailable or disagree about the target curve, the workflow should stop new price-driven actions and expose a clear stale or unavailable state. This paper measures successful server-side notification latency, not the behavior of a particular n8n instance.

## Research question

The research question is whether webhook delivery or fixed-interval polling provides the more dependable signal for triggering an n8n workflow after a day-ahead curve becomes complete. Dependability has at least three dimensions: detection delay, probability of eventually observing the publication, and probability of executing exactly once.

The available evidence directly measures only the first dimension for successful notifications. It supplies `detected_at`, `notified_at`, and their difference for production auction publication receipts. The polling comparator is a declared 30-second interval, not a captured sequence of actual n8n polls. Delivery failure and duplicate-action rates are not present.

The question is therefore reframed as an architecture decision under incomplete observability. Does the measured latency justify a webhook fast path, and what controls are needed so polling can add recovery without creating duplicate commands? The paper’s criterion is fail-closed exactly-once intent: a workflow may act only after validating one complete publication identity, regardless of how many transport observations arrive.

## Data and provenance

The evidence JSON identifies `VOLT-HOME-WP-093`, schema `volt-home-paper-evidence-v1`, status `measured`, and publication cutoff 2026-08-30T00:00:00Z. It records a common detailed window from 2025-10-01 through 2026-08-29 and broader corpus windows. The relevant input is the `auction_publications` contract, with related family contracts for grid revisions, ingestion runs, public API schemas, and repository integration fixtures.

The auction rows originated in a read-only production snapshot. Each selected row carried zone, delivery date, period count, complete-curve detection time, notification time, and detection-to-notification seconds. The frozen snapshot SHA-256 is `7e97489fc8528c8cc8c38830e05b48d949ce1f67b98575dff26f5d7c321e4c67`. The analysis-code SHA-256 is `57c57de79cdab2b5b6d6c54c485cb5162598c5ba0b0bfe995da40d75e6c52ba9`; the protocol SHA-256 is `adb36bf6b447af9f96339249b8becaefc20422499cca1977242866347a97bd4b`; the paper-registry SHA-256 is `7bcb91d7476d0a69fe9fa75a5c7782f8117e0153f82f9112b7e1d307d3943717`; and the source-registry SHA-256 is `07949550ac443ff673fda5c0209b99f137544f3ffecf6775f109bb9d09663bd6`. The evidence-manifest hashes are `441e8c73fcb207c3557300feb9ea938827174562e9611c346cde0812a94fc137` for the JSON and `5ce86592d535d992e889ec7347701a9c92243ae9db3479ace56870cbb69eafdf` for the WebP figure. Provenance also records a read-only-transaction flag and a 180-second statement timeout.

These are production notification receipts in the serving infrastructure. They are not n8n execution receipts, upstream exchange publication timestamps, customer-device acknowledgements, or records of a controlled packet-loss experiment. The fixed 30-second poll is an assumption. Proposed webhook drops or duplicate deliveries are fixtures for reasoning and future conformance work; no repository test execution is claimed.

## Method

The analysis collected finite `notification_seconds` values from 2,141 auction publication receipts and calculated their median. It fixed the polling interval at 30.0 seconds and defined the primary outcome as `30.0 - median(notification_seconds)`. The public evidence rounds that difference to 30.0 seconds. This construction approximates a comparison against waiting one full polling interval; it is not a randomized observation of polling phase.

The regenerated evidence records `bootstrap_95_interval: null` and `interval_method: "not reported for this estimand"`. No interval is available for the transformed polling-minus-webhook result, so this paper makes no uncertainty claim around the 30.0-second advantage.

For integration design, the observed transport event should be converted into a canonical publication key. A practical key includes event type, zone, delivery date, source publication or revision identity, and a complete-curve hash. Webhook and poll observations call the same validation and deduplication path. The action record should move monotonically from unseen to validated to armed to completed, with retries reading that state rather than emitting blind duplicate commands.

Webhook-only design minimizes delay but has no independent recovery path. Poll-only design is operationally simple but intentionally adds delay and repeated load. A hybrid adds state and deduplication complexity, yet it addresses both limitations. The evidence supports that tradeoff because the fast path is materially below the declared poll cadence while the unmeasured failure dimensions counsel against removing reconciliation.

## Results

The artifact reports a primary result of 30.0 seconds for “median webhook latency advantage over 30-second polling,” based on 2,141 receipts. Its declared interpretation is: webhooks reduce expected detection delay when delivery succeeds; polling remains a recovery path. The chart shows the successful webhook delay beside the 30-second poll comparator.

![Chart for Polling or webhooks: which gives n8n the more reliable auction signal?: median webhook latency advantage over 30-second polling, shown as webhook, 30s polling.](/research-media/home-papers/polling-or-webhooks-which-gives-n8n-the-more-reliable-auction-signal.webp)

The figure reports exactly 0.0 seconds for the successful-webhook comparator and 30.0 seconds for fixed-cadence polling. The evidence reports no interval for the transformed advantage, and none is inferred from the underlying notification-delay distribution.

The result demonstrates a latency advantage for successful webhook fan-out relative to the declared cadence. It does not establish higher end-to-end availability, because unsuccessful webhooks are not represented as timed successes and actual poll timing was not observed. It also does not measure n8n processing time after receipt.

## Robustness and placebo checks

The principal robustness concern is polling phase. If publication occurs uniformly between polls, expected poll wait would differ from the full 30-second cadence used by the frozen comparator. The evidence does not expose a phase-matched polling simulation, so the 30.0-second headline should be read as comparison with one fixed polling interval, exactly as preregistered, not as a universal expected-delay estimate.

A future deterministic conformance suite should inject a dropped webhook, duplicate webhook, delayed webhook, out-of-order revision, poll response arriving first, and both transports arriving together. These are recommended fault-injection fixtures, not measured repository results. Every case should converge on one action intent. A no-publication placebo should produce no action even though polls continue. An incomplete-curve placebo should remain quarantined until completeness is proven.

Production monitoring should separately count complete publications, webhook delivery attempts, acknowledgements, retries, dead letters, poll detections, duplicate observations, and unique actions. Without those denominators, “reliable” cannot be reduced to latency. The current result remains descriptive; the family’s Holm rule applies to inferential claims, and none is promoted here.

## Limitations

Successful notification receipts may omit or underrepresent failures by construction. The evidence does not state how many publication events lacked a notification receipt. It does not observe n8n, its queue, credentials, network path, or destination response. It measures server-side complete-curve detection to notification, not exchange gate closure to household action.

The polling comparator is assumed. Real polling can be faster or slower depending on cadence, jitter, rate limits, workflow scheduling, API latency, and phase relative to publication. Polling can also fail. No request-cost or rate-limit analysis is included.

The rounded 30.0-second headline has no reported uncertainty interval. The absence of an interval limits uncertainty interpretation, and this paper does not invent one.

Finally, no customer device, local n8n deployment, or repository integration suite was measured. The outcome does not prove exact-once execution. It only motivates an architecture capable of enforcing it.

## Practical implication

Build one n8n ingestion boundary with two callers. The webhook caller verifies the event envelope and fetches or accepts the complete curve. The polling caller periodically asks for the target delivery date and stops once the same publication key is reconciled. Both call a shared validation node and write to a durable action ledger before controlling a device.

Require the curve’s zone, delivery date, interval coverage, native resolution, publication or revision identity, and freshness. Derive an idempotency key from canonical fields, not transport-specific delivery IDs alone. If the key is already completed, record the duplicate and exit successfully. If it is in progress, avoid concurrent control. If the content hash changes under the same delivery date, treat it as a revision and apply an explicit update policy rather than replaying the original action.

Configure a reconciliation deadline and an appliance-safe fallback. If neither transport yields a complete valid curve by the deadline, withhold optional optimization and use the operator-declared baseline. Never substitute partial data or yesterday’s target without a freshness rule. Alerting should distinguish “webhook missed but poll recovered” from “no valid publication,” because the operational remedies differ.

## Reproducibility

To reproduce the frozen number, verify all five provenance hashes and both evidence-manifest artifact hashes, select finite notification delays from the frozen auction publication rows, compute the median, subtract it from 30.0 seconds, and apply the same publication formatting. Confirm a sample size of 2,141, the rounded primary value of 30.0 seconds, and the absence of a reported interval.

A follow-up reliability study should preregister separate metrics before collecting outcomes: successful-delivery rate, recovery rate, duplicate-observation rate, unique-action rate, end-to-end latency, and stale-action rejection. It should identify actual n8n and adapter versions and publish production receipts separately from deterministic fault-injection fixtures.

Using a later snapshot or a different polling cadence would be a replication, not a reproduction. It should receive a new cutoff and evidence hash rather than altering this paper’s fixed assumptions.

## Disclosure

Analysis and drafting were model-assisted. This is a public working paper. It is not peer reviewed. The production-origin receipts, analysis assumptions, evidence hashes, and limitations are disclosed. The internal architecture reference is published by Voltcast.

No n8n deployment, household network, or customer device was measured. No repository test pass is claimed. Volt has no live traders or live capital; C0R is its only paper strategy, and production weather forecasting is non-trading. This paper is not trading advice, an availability guarantee, or a promise of savings.

## References

1. Google Search Central, [Article structured data](https://developers.google.com/search/docs/appearance/structured-data/article).
2. Google Search Central, [Introduction to structured data markup in Google Search](https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data).
3. Google Search Central, [Spam Policies for Google Web Search — Scaled content abuse](https://developers.google.com/search/docs/essentials/spam-policies).
4. ENTSO-E, [Single Day-ahead Coupling (SDAC)](https://www.entsoe.eu/network_codes/cacm/implementation/sdac/).
5. Voltcast, [Voltcast Architecture](https://github.com/ossedk/voltcast/blob/main/docs/voltcast/ARCHITECTURE.md).