Cómo normalizar datos de 33 fuentes que no se parecen en nada

Cuando juntás datos de muchos sistemas públicos, lo que cuesta no es pedirlos. Es que ninguno se parece al otro. Te llega un HTML viejo de uno, un JSON medio escondido de otro y un PDF del tercero, y los tres hablan de lo mismo con palabras distintas. La única forma de que tu producto no se vuelva un infierno de casos especiales es elegir un único formato de salida y traducir todo a eso.

El problema, con un ejemplo

En Multita consultamos multas de tránsito en más de 33 sistemas oficiales argentinos. Un portal devuelve la fecha como "12/03/2026", otro como "2026-03-12", y un tercero la mete en una celda de una tabla sin etiqueta. Uno marca "PAGA", otro "Cancelada", otro "sin deuda". Tres maneras de decir lo mismo.

Si dejás que esas diferencias lleguen a tu lógica de negocio, cada cálculo se llena de "si la jurisdicción es tal, entonces". Multiplicá eso por 33 y no mantenés nada.

Un contrato de salida, y un traductor por fuente

La regla que nos ordenó todo: un solo schema de salida, y un adaptador por fuente que traduce a ese schema. La lógica de negocio conoce el schema, nunca el portal.

{
  "jurisdiccion": "pba",
  "estado": "deuda",
  "monto": 209250,
  "fecha": "2026-03-12"
}

• Los estados se reducen a un set chico y comparable (deuda, pago_voluntario, en_juzgado, sin_deuda).
• Los montos van siempre en pesos enteros, aunque la fuente los exprese en una unidad que se actualiza sola.
• Las fechas, siempre ISO.

El adaptador hace el laburo sucio y el resto del sistema vive limpio.

Lo que ganás

Cuando aparece la fuente 34, no tocás la lógica: escribís un adaptador y listo. Y cuando un portal cambia su HTML (pasa seguido), el incendio queda en un solo archivo. Esa separación es la que hace que la API de Multita devuelva una respuesta consistente sin importar de dónde salió el dato.

Si vas a integrar varias fuentes que no controlás, definí el formato de salida antes de escribir el primer scraper. Es la decisión que más dolor te ahorra después.