Fuel & Energy Data Scraping Services

Depends on tier and market. Our standard tier refreshes twice daily, which suits most pricing processes since forecourt prices typically change once or twice a day. The hourly tier captures intraday changes and change-event timestamps, which is what you need to identify local first movers.

In markets with mandated real-time price reporting — Germany, France, parts of Australia — we can deliver closer to source publication frequency. Every record carries an observed_at timestamp so you can measure freshness directly rather than relying on our claim.

We poll connector status repeatedly and aggregate our own observations into a rolling 30-day availability percentage. Operator figures are calculated inconsistently — definitions differ on partial availability, planned maintenance and reduced-power sessions — which makes cross-network comparison meaningless.

Our definition is documented explicitly, including polling frequency and how partial availability is treated. That means you can assess whether it suits your purpose, and it means uptime is comparable across every network in the service because one definition applies throughout.

Yes, and this is usually the field clients build their reporting on. Every site carries coordinates, and we compute position against the average within a radius you configure — delivered as a field rather than something you calculate downstream.

The radius should reflect driver behaviour in your market: tighter in dense urban areas, wider on rural corridors. We can deliver multiple radii simultaneously if your estate spans both, so an urban site and a motorway site are each assessed against a realistic competitive set.

Where they exist, yes, as the primary source — Germany's MTS-K, France's Prix Carburants and Australia's state schemes among them. They are authoritative and mandated.

We also run site-level collection as validation and flag discrepancies between the official feed and the displayed price. This matters: official feeds occasionally lag actual forecourt changes, and knowing when they diverge is useful for anyone making same-day pricing decisions.

Yes, where networks publish them. Charging pricing is more complex than fuel: ad-hoc versus membership rates, session and connection fees, idle fees, and peak versus off-peak variation all affect what a driver actually pays.

We extract the full tariff structure where published rather than a single headline rate, because a network with a low per-kWh rate and a high connection fee can be more expensive than it appears for short sessions. Where a network publishes only app-visible pricing, we mark it as unavailable rather than substituting an estimate.

By extracting the components rather than a computed annual figure. Standing charge, unit rate, tariff type, contract length, exit fees and any green or fuel-mix claims are captured as separate fields.

We deliberately avoid publishing a single 'annual cost' comparison, because that figure depends entirely on assumed consumption — and a comparison valid for a high-consumption household is misleading for a low-consumption one. With components delivered separately, you apply your own consumption profiles, which is where the analysis actually belongs.

Yes. Stable site IDs mean we detect when a site appears in or disappears from an operator's network, with first-seen and last-seen dates attached. Network expansion tracking is a common request from investors and from operators doing competitive site planning.

One caveat: a site vanishing from a locator can mean permanent closure, temporary closure, or a locator data error. We flag disappearance and confirm across subsequent runs before classifying it as a closure, rather than reporting every absence as a shutdown.

Technically yes, and clients do build with it. Two things to consider. First, consumer apps need high refresh frequency and low latency, which pushes you toward the hourly tier and increases cost. Second, displaying a price that turns out to be wrong damages user trust quickly, so surfacing the observed_at timestamp in your UI is strongly advisable.

Some official feeds also carry attribution or redistribution conditions. We flag which sources have such terms during scoping so you can assess them before building a product on that data.

We quote every fuel and energy data engagement individually, because a real number depends on scope: source count, record volume, refresh frequency and delivery method. Anyone quoting you a price before understanding those four things is guessing.

Site count and refresh frequency drive cost most; the hourly tier costs materially more than twice-daily because polling volume scales directly with it.

The process is short: one scoping call, a free pilot on your own sources within 48 hours, then a fixed monthly quote. No per-request metering, no overage billing, and field or source additions are handled inside the retainer rather than re-quoted. Request a quote.