API de datos de consumo de CFE

Sí: puedes obtener los datos de consumo de CFE con una API, sin capturar números del portal ni del PDF. Conectas tu cuenta de CFE una sola vez y, a partir de ahí, una API descarga cada recibo y expone su consumo —los kWh, la demanda y su desglose por horario— como JSON, listo para analizar. Este es el flujo que resuelve la API de Batu: en vez de leer recibo por recibo cada mes, tu integración pide el consumo de un contrato y recibe una serie estructurada.

Esta guía explica qué son exactamente los datos de consumo de CFE, por qué el consumo (kWh) y la demanda (kW) no son lo mismo, qué te entrega la API por tarifa, y cómo pedir el consumo de un RPU con un ejemplo en curl, JavaScript y Python.

Qué son los datos de consumo de CFE (y por qué viven atrapados en el recibo)

Los datos de consumo de CFE son las cifras que CFE mide y factura en cada recibo:

• La energía consumida en el periodo, en kWh —el total del "cuánto"—.
• La demanda máxima, en kW, en las tarifas que la cobran: la potencia media del intervalo de 15 minutos de mayor consumo del periodo.
• En tarifas horarias, el desglose por bloque —base, intermedia y punta—, porque la misma energía cuesta distinto según la hora.

El problema no es que el dato no exista, es que vive atrapado en un formato pensado para leerse con los ojos: un PDF mensual y, en tarifas de demanda, un XML asociado. Para analizar el consumo de un contrato —su tendencia, sus picos, sus meses fuera de rango— tienes que sacar esos números uno por uno. Multiplícalo por decenas de RPUs y por cada cierre de facturación, y el consumo deja de ser un dato accionable para volverse una tarea de captura.

Una API invierte eso: el consumo de cada recibo llega ya estructurado, en llaves estables, para que tu sistema lo use directamente en vez de leerlo a mano. Si lo que buscas es descargar el recibo completo —no solo su consumo—, lo cubrimos en Cómo descargar recibos de CFE con una API.

Consumo (kWh) y demanda (kW): no son lo mismo

Es la distinción que más se confunde, y la que hace que el dato de consumo de CFE sea más rico de lo que parece. El consumo es energía (kWh): cuánta usaste en total. La demanda es potencia (kW): qué tan rápido la usaste en tu peor momento del periodo —la potencia media del intervalo de 15 minutos de mayor consumo—.

Dos sitios pueden consumir los mismos kWh y facturar demandas muy distintas, según la forma de su consumo. Por eso CFE cobra las dos cosas por separado en las tarifas de demanda, y por eso una API de consumo te entrega ambas: sin la demanda, solo ves la mitad de la historia.

La demanda, además, se factura en dos componentes que conviene no confundir: capacidad —ligada a tu demanda en el bloque de punta— y distribución —ligada al pico de demanda del mes—. El detalle de cómo se calcula la demanda facturable está en Demanda contratada de CFE; aquí basta con saber que la demanda medida viaja junto al consumo de cada periodo.

Qué datos de consumo entrega la API, según la tarifa

Qué conceptos de consumo trae un recibo depende de su tarifa. Estas son las tarifas comerciales e industriales más comunes y qué datos de consumo entregan:

El caso más rico es una tarifa horaria como la GDMTH: el recibo no solo dice cuánta energía usaste, sino cuándo. Esa es la parte del dato de consumo con más valor, porque cada bloque se cobra a distinto precio:

Los horarios de cada bloque varían por división de CFE —son 16 en total— y por temporada, verano y fuera de verano; en Baja California existe además un cuarto bloque, "semipunta". Una API para datos de consumo absorbe esa variabilidad: sin importar la tarifa, la división o la temporada, te entrega el consumo en la misma estructura, así tu análisis no se rompe cuando cambian los horarios.

Cómo pedir el consumo de un contrato

En la práctica, obtener el consumo de un contrato es una petición autenticada. La API de Batu vive en app.batuenergy.com/api/v1, y te autenticas con tu API key como Bearer token en el encabezado Authorization. Cada recibo de un RPU trae el consumo de su periodo, así que pides los recibos de ese contrato y de ahí sale la serie:

# Autenticación: API key como Bearer token en el encabezado Authorization
curl "https://app.batuenergy.com/api/v1/bills?rpu=TU_RPU" \
-H "Authorization: Bearer TU_API_KEY"

La respuesta trae un objeto por periodo, cada uno con su bloque contract y sus conceptos de consumo —kwh, demandaMaxima, factorPotencia— ya normalizados. Recorriendo los periodos armas la serie de consumo del contrato:

{
"status": "success",
"items": 2,
"total": 24,
"has_more": true,
"next_cursor": "eyJpZCI6ImJpbF8wMUpRMks…",
"data": [
  {
    "id": "bil_01JQ2K7R8MW3XZ",
    "object": "bill",
    "year_month": "2026-05",
    "period_start": "2026-04-01",
    "period_end": "2026-04-30",
    "tariff": "GDMTH",
    "contract": { "rpu": "123456789012", "pricing_zone": "Jalisco" },
    "concepts": {
      "kwh": "12450",
      "demandaMaxima": "48.20",
      "factorPotencia": "94.2"
    }
  },
  {
    "id": "bil_01JQ2K7R8MW3YA",
    "object": "bill",
    "year_month": "2026-04",
    "period_start": "2026-03-01",
    "period_end": "2026-03-31",
    "tariff": "GDMTH",
    "contract": { "rpu": "123456789012", "pricing_zone": "Jalisco" },
    "concepts": {
      "kwh": "11890",
      "demandaMaxima": "46.75",
      "factorPotencia": "93.8"
    }
  }
],
"concept_meaning": {
  "kwh": { "label": "kWh Totales", "units": "kWh" },
  "demandaMaxima": { "label": "Demanda Máxima", "units": "kW" },
  "factorPotencia": { "label": "Factor de Potencia", "units": "%" }
}
}

Un par de detalles que ahorran sorpresas: los valores numéricos viajan como cadenas de texto (así conservan la precisión decimal exacta del recibo) y los identificadores llevan un prefijo (bil_ para un recibo). Cuando un contrato tiene más periodos de los que caben en una página, el campo has_more te avisa y el next_cursor te deja pedir la siguiente, hasta recorrer todo el histórico. Los valores del ejemplo son ilustrativos; los límites de uso y el modelo de créditos dependen de tu plan de acceso.

De datos a decisiones: tendencias, anomalías y ahorro

Un mes de consumo aislado no dice mucho. El valor aparece cuando tienes la serie: todos los periodos de un contrato como datos, uno junto a otro.

Con la serie completa, tres cosas dejan de ser trabajo manual:

• Tendencia. Ves si el consumo sube, baja o se dispara con la temporada, sitio por sitio.
• Anomalías. Un salto fuera de rango —una lectura estimada, un equipo mal configurado, un cambio real de operación— salta a la vista y se revisa a tiempo, no tres meses después.
• Ahorro y facturación. Con los kWh por horario y la demanda como datos, alimentas directamente tus cálculos de ahorro, tus reportes o tu facturación a terceros. El desglose por bloque, además, apunta al ahorro más grande: mover consumo del bloque de punta.

El factor de potencia que viene en la misma respuesta cierra el panorama: junto al consumo y la demanda, es la tercera palanca de la parte controlable del recibo.

API o capturar los números a mano

Es tentador resolver esto con alguien que abra el portal, baje los PDFs y vacíe los números en una hoja de cálculo. Funciona con pocos contratos; a escala, no. El consumo capturado a mano llega tarde, con errores de dedo, y sin una serie confiable para analizar.

• Trabajo que se repite. Cada mes, cada RPU, el mismo recorrido.
• Errores de captura. Un kWh mal tecleado contamina la tendencia y esconde justo la anomalía que querías detectar.
• Sin estructura para analizar. Una hoja de cálculo no es una API: cada quien la arma distinto, y conectarla a un sistema es otro proyecto.

Un scraper propio del portal tampoco lo resuelve: el portal de CFE no es una API —no tiene contrato estable ni versiones— y se rompe cuando CFE cambia sin avisar. Ese análisis lo desarrollamos en el artículo sobre descargar recibos con una API. Con una API ya mantenida, el consumo llega estructurado y ese costo lo asume quien la opera.

Cómo lo resuelve Batu

Batu ya descarga recibos de CFE a escala y expone su consumo por API. Conectas la cuenta de CFE una vez y el consumo, la demanda y las tarifas quedan disponibles como datos estructurados: tú tomas la batuta y construyes encima —reportes de ahorro, detección de anomalías, facturación—, mientras nosotros nos encargamos de la parte tediosa de obtener y normalizar los datos de CFE. El acceso a la API es para cuentas autenticadas; puedes solicitar acceso o ver una demo.

Si en vez de construir sobre la API lo que quieres es gestionar el consumo de tu propia empresa multi-sitio —ver el consumo de todas tus sucursales, monitorear pagos y detectar anomalías—, eso lo cubre la plataforma de Batu directamente, sin escribir código.

• API de CFE: recibos, consumo y tarifas — la referencia de endpoints, autenticación y ejemplos.
• Cómo descargar recibos de CFE con una API — el recibo completo, no solo su consumo.
• Cómo leer el recibo de CFE — qué significa cada concepto que entrega la API.
• Calcula el costo de implementar Batu — estima créditos y plan según tu volumen de recibos y sitios.

Fuentes

• ACUERDO CT/11.SE/8-2025 — Comisión Nacional de Energía (CNE), publicado en el DOF el 23 de enero de 2026. Estructura tarifaria de CFE: tarifas comerciales e industriales, tensiones, bloques horarios (base, intermedia, punta) y factores de carga. La CNE absorbió a la Comisión Reguladora de Energía (CRE) en la reforma energética de 2025; los acuerdos previos de la CRE siguen vigentes bajo la CNE.
• Acuerdo A/064/2018 (mejorado bajo CT/11.SE/8-2025, Tabla 2) — demanda facturable y sus componentes de capacidad y distribución; la demanda máxima medida como potencia media del intervalo de 15 minutos de mayor consumo.
• Acuerdo A/158/2024 (DOF, 24 de enero de 2025) y Código de Red RES/550/2021 — factor de potencia y umbrales aplicables.
• API pública v1 de Batu — base URL, endpoints y forma de la respuesta de recibos (GET /api/v1/bills), de donde se obtiene el consumo de cada periodo. Los valores mostrados en los ejemplos son ilustrativos.