Summary

  • Britain’s Phase 1a API is designed to expose public supplier tariff prices in a standard form; it is not the later service for sharing a consumer’s specific tariff data with an authorised third party.
  • A supplier-specific Tariff ID distinguishes price records that can differ by payment method, location or other qualifiers. The public interface can list those records; a household or service still needs the right identifier to select one.

The price list is the easy part. The harder question is whether the right row belongs to the person looking at it.

On 30 October, the Department for Energy Security and Net Zero issued a decision under section 245(1)(e) of the Energy Act 2023. The change incorporates version 1.0 of the Tariff Interoperability API Technical Specification into the Retail Energy Code and amends the Energy Market Data Specification and Standards Definition Document. It takes effect on 6 November. The Phase 1a public Tariff Pricing Data API is planned for 18 February 2027.

The Government describes Phase 1a as standardised access to public tariff pricing data. Its stated use case works where consumers share their supplier and tariff details. That is a meaningful boundary: the API makes supplier prices easier to retrieve; it does not turn a public price catalogue into a consumer-specific account feed. Phase 1b, planned for November 2027, is the later route for consumer-specific tariff information to authorised third parties through arrangements aligned with the Consumer Consent Solution.

The technical notice makes the identity problem visible. A tariff list is requested at GET /tariffs/{supplier_mpid}; details for a selected record are requested at GET /tariff/{supplier_mpid}/{tariff_id}. The Tariff ID is supplier-specific and identifies a set of price data. Two records can reflect different payment methods or locations. The same Tariff Name can be attached to several IDs, and a name can even be identical to its ID. The label that looks friendly is therefore not a dependable key.

Records also carry dates: last modified, effective and sellable. Qualifiers can identify payment method, geographic group, meter type and tariff type. An automation that finds a plausible price but drops one of those distinctions can produce a polished answer for the wrong contract. That is a design risk, not a reported incident: the official material reviewed here documents the schema and timetable, not a household harmed by a bad match.

The governance test is a receipt for the match. A comparison service should be able to show which supplier MPID and Tariff ID it used, which qualifiers matched the consumer’s stated details, and which effective date controlled the result. When the match is ambiguous, the service should ask for the missing detail instead of pretending a tariff name settles the matter. That small record makes a recommendation contestable by the person who pays the bill.

The specification standardises how prices are exposed. Accountability still depends on how a real tariff is selected from them. The public go-live should be judged on both: can software retrieve the record, and can a household see why that record was called its own?

Sources