Proxies for Energy Tariff and Fuel Price Data

The sources below were checked in September 2026. Reporting rules and access terms change, so confirm each on the publisher's own page before you design around it.

Two practical notes. France's publisher points out that a 10-minute feed does not mean every station changes its price every 10 minutes, and it shows a last-updated date per price for that reason. And Tankerkönig's API terms ask for attribution under CC BY 4.0 and no more than one request every 5 minutes, which is a useful reminder that "open" data still has conditions.

If your market is in this table and the feed covers the fields you need, you may not need proxies at all for the core dataset.

Official feeds leave real gaps, and those gaps are where most commercial energy price work sits.

• US and Canadian station prices. There is no national station-level reporting mandate in the US comparable to the European schemes above, and the EIA's weekly series is an average. Station-level prices come from brand store locators, retailer websites and apps.
• Supplier tariff pages. Unit rates, standing charges, contract lengths and exit fees for fixed deals are published by each supplier, often behind a postcode lookup, and rarely in a feed.
• Business and commercial tariffs. Price caps and consumer plan APIs mostly cover households. Business rates are scattered across supplier and broker sites.
• Delivered fuels. Heating oil, LPG and bulk diesel are quoted by volume and delivery postcode by local distributors, with no central register.
• EV charging prices. Per-kWh, per-minute and session fees vary by network, charger speed, membership and time of day, and are published network by network.
• Feed verification. Reporting regimes are new or unevenly enforced in places. Sampling what a retailer's own site displays against the official record catches stale or missing stations.
• Comparison-site views. What a switching site ranks first for a postcode is a commercial signal in its own right, although these sites often restrict automated access in their terms.

Energy suppliers and fuel retailers also defend their pages the way any retailer does. Rate limits and bot checks on store locators and quote journeys are the same problem covered for supermarkets in proxies for grocery and delivery prices, with one difference that shapes everything below: the unit of data.

Read the "main cost driver" row carefully, because it decides which proxy billing model hurts. Fuel collection is many small requests: a per-request or per-IP limit is the constraint, and bytes barely register. Tariff collection is fewer, heavier sessions with a headless browser pulling scripts and assets at every step: on a per-GB plan that is where the bill grows. How to reduce proxy bandwidth costs covers blocking assets you do not need, which matters far more for the tariff side.

Poll at the speed prices change on your source, not at the speed your infrastructure allows. Two illustrative workloads show the range. The numbers are assumptions for sizing, not measurements.

Fuel: a regional US brand locator. Assume 1,200 stations, each returning all grades in one JSON response.

Even the aggressive end is 120 requests a minute, a light load for any proxy plan. The limiting factor is how the locator treats repeated calls from the same address, so rotation matters more than concurrency. And polling every 10 minutes buys little if the brand changes prices a few times a day. Store only changes, and let the change log tell you whether to poll faster.

Tariffs: a UK supplier sweep. Assume 30 suppliers, 40 representative postcodes, and 3 meter or consumption profiles, run weekly. That is 3,600 quote journeys a week. If each journey loads 6 rendered pages, the week is 21,600 page renders. Few requests by fuel standards, but each render may weigh one to three megabytes once scripts and assets are counted, which puts the weekly transfer somewhere in the tens of gigabytes before any asset blocking. Here, concurrency controls how long the sweep takes and bandwidth controls what it costs.

Most location-sensitive scraping depends on exit IP geography. Energy data mostly does not, and buying city-level proxies for it is usually wasted money.

A station's price belongs to the station. The locator returns it with an ID and coordinates, regardless of where your request comes from. A tariff quote depends on the postcode and meter details you enter, because regional distribution charges vary. Your IP does not change what a supplier charges in a given postcode.

The IP still matters at country level:

• Some suppliers and fuel retailers serve a different site, or refuse service, to visitors outside their home country.
• Currency, VAT display and language can follow the visitor's country.
• A bot-check system is more suspicious of a foreign datacenter address hitting a domestic-only quote journey.

So match the exit country to the market, and put the real location into the request parameters. For how geo-targeting works in general and where finer targeting does matter, see what geo-targeting means in proxies.

The sticky-session row is the one teams miss. A quote journey that starts on one IP and submits its postcode from another looks like a hijacked session to many form handlers, and fails in ways that resemble parser bugs. Hold one exit for the whole journey, then rotate before the next. The underlying trade-off is laid out in residential vs datacenter proxies.

Energy prices are some of the least comparable numbers you will collect. Settle the schema before the scraper.

Fuel

• Units. Pence per litre, euros per litre, dollars per US gallon. Convert to one unit and keep the original.
• Precision. Many European and US displays carry a tenths digit, such as 1.749 or $3.29 9/10. Store the full precision you are shown.
• Grade names. "Super E10", "Unleaded", "Regular 87" and "SP95-E10" need a mapping table per market.
• Timestamps. Record both when the retailer says the price took effect, where given, and when you observed it.

Tariffs

• Two-part pricing. A unit rate per kWh plus a standing charge per day. Neither alone tells you the cost.
• Time-of-use bands. Peak, off-peak and weekend windows with their own rates and clock times, often in local time with daylight saving changes.
• Tax. Whether a displayed rate includes VAT or sales tax differs by page and by customer type.
• Contract terms. Fixed length, exit fees and end-date behaviour are part of the product.

The only fair comparison between tariffs is an annual cost for a stated consumption profile. A minimal calculator makes the point:

def annual_cost(unit_rates_p, band_share, standing_p_per_day, kwh_per_year, days=365):
    """Annual cost in pounds for a (possibly time-of-use) tariff.

    unit_rates_p: pence per kWh per band, e.g. {"peak": 27.1, "off_peak": 8.5}
    band_share:   share of consumption in each band, summing to 1.0
    """
    energy = sum(kwh_per_year * band_share[b] * unit_rates_p[b] for b in unit_rates_p)
    standing = standing_p_per_day * days
    return round((energy + standing) / 100, 2)

# Illustrative tariffs only, not real supplier prices
flat = annual_cost({"all": 24.5}, {"all": 1.0}, 53.0, 2700)
tou  = annual_cost({"peak": 29.0, "off_peak": 9.0}, {"peak": 0.6, "off_peak": 0.4}, 58.0, 2700)
print(flat, tou)   # 854.95 778.7

With those invented numbers, the time-of-use tariff is about £76 a year cheaper for a household using 40% of its power off-peak, and becomes the more expensive option once the off-peak share drops below roughly 26%, because its standing charge is higher. The scraper's job is to capture every input to that function correctly. The calculator's job is to stop anyone ranking tariffs by unit rate alone.

For fuel, the equivalent discipline is a change log rather than snapshots:

last_seen = {}   # (station_id, grade) -> price

def record(station_id, grade, price, observed_at, sink):
    key = (station_id, grade)
    if last_seen.get(key) != price:
        sink.append({"station": station_id, "grade": grade,
                     "price": price, "observed_at": observed_at,
                     "previous": last_seen.get(key)})
        last_seen[key] = price

A change log is smaller, answers "when did this station move" directly, and tells you empirically how often your source changes, which feeds back into the polling interval. The broader pipeline pattern is in building an automated price monitoring system with proxy rotation.

SparkProxy is datacenter-first, which fits the two workloads above differently, so here is where it helps and where it does not.

Fuel locators. Rotating datacenter proxies with per-request rotation on gateway.sparkproxy.io:11000 spread locator calls across a 1M+ IP pool in 80+ countries, including 50,000+ US IPs. Plans are sized by concurrent threads, and the fuel workload above needs very few. Starter at $75 a month for 100 threads is already far more parallelism than a 1,200-station poll requires, so only choose a larger plan if other collection shares the account.

Tariff journeys. Port 11002 holds one exit IP for a session window, which is what a multi-step quote form needs. Every plan has unlimited bandwidth, so heavy rendered pages do not change the bill; the Fair Usage speed ceiling (25 Mbps on Starter up to 150 Mbps on Plus) is the practical limit, not a monthly allowance.

When you would rather not run browsers. The Scraping API renders pages, rotates and retries behind one call. A plain fetch costs 1 credit, a JavaScript render 5, and routing through a specific country adds 5, so a rendered GB-routed page is 10 credits. There are 1,000 free credits with no card, and paid plans start at $49 for 250,000 credits a month.

curl -G "https://scrape.sparkproxy.io/api/v1" \
  -H "X-API-Key: $SPARKPROXY_API_KEY" \
  --data-urlencode "url=https://supplier.example/tariffs/fixed" \
  --data-urlencode "render_js=true" \
  --data-urlencode "country_code=GB" \
  --data-urlencode "tag=tariffs:weekly"

What SparkProxy does not do: it sells no residential or mobile proxies and no city-level targeting. For scraping jobs, the SparkProxy Scraping API does offer residential exits through its premium_proxy option, which routes a request through a residential pool for 10 credits, or 25 with JavaScript rendering. If a supplier or comparison site blocks datacenter networks outright, you need a different proxy type for that source.

• Open data licences carry obligations. Attribution requirements, rate limits and redistribution terms apply even to free feeds. Keep a register of which licence each dataset arrived under.
• Website terms differ from open data. Comparison sites and some suppliers restrict automated access in their terms. Read them, and get legal advice before collecting at commercial scale or republishing.
• Never enter real personal data into quote forms. Use published tariff tables, tariff information documents and quote steps that return prices from a postcode alone. If a journey requires a name, email or account number to show a price, treat that source as out of scope rather than inventing details.
• Be a light visitor. Pace requests per domain, cache pages that have not changed, and schedule sweeps outside the site's peak hours. Small distributors run small servers.