Resumen

  • La fase 1a abre el acceso normalizado a datos públicos de precios de proveedores; no es todavía el canal posterior para compartir datos tarifarios de un consumidor concreto con un tercero autorizado.
  • El Tariff ID, específico de cada proveedor, separa registros que pueden cambiar por forma de pago, zona u otros criterios. Enumerar registros no resuelve por sí solo cuál pertenece a un hogar.

El catálogo puede estar impecable y aun así enseñar el precio de otra persona.

El 30 de octubre, el Department for Energy Security and Net Zero dictó una decisión al amparo de la sección 245(1)(e) de la Energy Act 2023. La decisión incorpora la versión 1.0 de la especificación técnica de la Tariff Interoperability API al Retail Energy Code y modifica la Energy Market Data Specification y el Standards Definition Document. Entrará en vigor el 6 de noviembre. La API pública de precios de la fase 1a tiene como fecha prevista de lanzamiento el 18 de febrero de 2027.

El Gobierno presenta esta fase como acceso normalizado a los precios públicos de proveedores, útil cuando el consumidor comparte quién le suministra energía y qué tarifa tiene. El límite importa: se publican más fácilmente los registros del proveedor, pero el catálogo no se convierte en una lectura individual de la cuenta del hogar. La fase 1b, prevista para noviembre de 2027, es la que contempla información tarifaria específica del consumidor para terceros autorizados mediante acuerdos alineados con la solución de consentimiento.

La especificación enseña por qué la coincidencia requiere cuidado. GET /tariffs/{supplier_mpid} devuelve la lista de un proveedor; GET /tariff/{supplier_mpid}/{tariff_id} pide el detalle de un registro concreto. El Tariff ID es específico del proveedor y representa un conjunto de datos de precio. Puede haber identificadores distintos por método de pago o ubicación. El mismo nombre de tarifa puede aparecer con varios IDs, y el nombre puede coincidir con el ID. Buscar por una etiqueta atractiva no basta.

Los registros incluyen última modificación, fecha efectiva y fecha de venta; también admiten criterios como pago, zona geográfica, tipo de contador y clase de tarifa. Un sistema puede recuperar el precio correcto en apariencia y perder justo la distinción contractual decisiva. Las fuentes consultadas describen esa estructura, no un caso de un consumidor perjudicado: aquí hablamos de un fallo posible de control, no de un daño ya observado.

Por eso la prueba útil no es una captura de la API funcionando. Es un comprobante que muestre MPID, Tariff ID, criterios coincidentes y fecha efectiva, junto con el dato del consumidor que permitió elegir esa fila. Si dos resultados siguen encajando, el servicio debe preguntar. Una recomendación visible se puede discutir; una coincidencia oculta acaba convertida en autoridad por pura comodidad.

La fase 1a ordena la publicación de precios. El lanzamiento también debe demostrar que la selección entre registros se puede explicar al hogar que pagará la factura.

Fuentes