POST /sips/internal POST /sips/external

🔁 Consulta SIPS Global (Electricidad / Gas)

Endpoint unificado que devuelve los datos del CUPS sin que el cliente tenga que saber si es electricidad o gas. Si la primera consulta no devuelve datos, se prueba con el otro tipo para distinguir entre un CUPS de otro suministro y un CUPS sin datos en SIPS.

📝 Descripción

Las rutas /sips/internal y /sips/external comparten el mismo handler y la misma lógica. Se mantienen separadas para poder aplicar políticas distintas (rate-limit, logging, IPs permitidas, etc.) sin tocar el código del endpoint.

El comportamiento depende del campo type recibido en el body:

type = "elec" → consulta electricidad (obtener_datos_cups). Si no hay datos, prueba gas como fallback de diagnóstico.
type = "gas" → consulta gas (obtener_datos_cups_gas). Si no hay datos, prueba electricidad como fallback de diagnóstico.

🔐 Autenticación

Requiere JWT (@require_jwt). El token estático API_SECUR_TOKEN no es válido aquí. El JWT debe estar firmado con JWT_SECRET o JWT_SECRET_1 con algoritmo HS256.

⚠️ Diferencia con el resto de endpoints: los endpoints /sips/<cups> y /sips_gas/<cups> aceptan token estático. Estas dos rutas, no.

📥 Cuerpo de la petición

Campo	Tipo	Requerido	Descripción
`cups`	string	Requerido	Código CUPS a consultar.
`type`	string	Requerido	Tipo de suministro: `"elec"` o `"gas"`.

Ejemplo

{
  "cups": "ES0031405678912345AB1F",
  "type": "elec"
}

📤 Respuesta exitosa (200 OK)

Devuelve el mismo objeto JSON que el endpoint /sips/<cups> cuando type = "elec" o que /sips_gas/<cups> cuando type = "gas". Consulta:

❌ Errores y diagnóstico cruzado

La lógica de "fallback diagnóstico" diferencia tres situaciones cuando SIPS no devuelve datos para el tipo solicitado:

Código	Mensaje	Significado
`400`	`El parámetro 'type' debe ser 'elec' o 'gas'`	Se ha enviado un `type` distinto de los dos valores admitidos.
`400`	`CUPS parameter is required`	Falta el campo `cups` en el body.
`400`	`CUPS no reconocido como electricidad` / `... como gas`	SIPS no tiene datos para el tipo solicitado, pero sí los tiene para el otro tipo. El CUPS existe, pero es del suministro contrario al pedido.
`400`	`No hay datos para el CUPS <cups>`	SIPS no tiene datos ni para electricidad ni para gas para ese CUPS.
`401`	`Autenticación requerida` / `Token inválido`	Cabecera `Authorization` ausente o JWT no válido / expirado.
`5xx`	Variable	Error externo de SIPS o error interno; se reenvía el código original si está disponible.

ℹ️ Uso típico: llama primero con el type que esperas. Si recibes "CUPS no reconocido como X", ya sabes que tienes que cambiar de circuito (de electricidad a gas o viceversa) sin necesidad de hacer dos peticiones.

💻 Ejemplos

cURL

curl -X POST "https://api.imaginaenergia.com/sips/internal" \
  -H "Authorization: Bearer <JWT>" \
  -H "Content-Type: application/json" \
  -d '{"cups": "ES0031405678912345AB1F", "type": "elec"}'

Python

import requests

r = requests.post(
    "https://api.imaginaenergia.com/sips/internal",
    headers={"Authorization": f"Bearer {jwt}"},
    json={"cups": cups, "type": "elec"},
    timeout=30,
)

if r.status_code == 200:
    datos = r.json()
elif r.status_code == 400 and "no reconocido" in r.json().get("error", ""):
    # Reintentamos con el otro tipo
    r = requests.post(
        "https://api.imaginaenergia.com/sips/internal",
        headers={"Authorization": f"Bearer {jwt}"},
        json={"cups": cups, "type": "gas"},
        timeout=30,
    )
    datos = r.json()