DEV Community: Multita

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

Multita — Mon, 06 Jul 2026 03:00:00 +0000

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.

Un solo event loop, captchas y reintentos: lo que aprendí scrapeando portales de gobierno

Multita — Wed, 01 Jul 2026 12:32:00 +0000

Detrás de la API de Multita hay un servicio que consulta portales de gobierno argentinos en vivo, en el momento en que se hace la consulta. Estas son las decisiones que más me costó aprender, contadas para que a vos te cuesten menos.

1. No bloquees el event loop, nunca

Parece obvio hasta que te pasa. Con un solo worker async, una operación bloqueante en una ruta (un hash de contraseña, una escritura pesada a la base) te frena todas las consultas en vuelo. La regla quedó grabada: lo bloqueante va a un thread aparte, con un semáforo que limita cuántos corren a la vez, y la ruta que dispara un trabajo largo responde al toque con un "recibido" y deja que el resultado se resuelva por atrás. El submit no espera al scraping.

2. Los captchas no se "resuelven", se torean

Los captcha modernos basados en score no se rompen: se conviven. Lo que más me ordenó fue entender que el token tiene que generarse en el contexto correcto (la página del formulario, no el endpoint que recibe los datos), o el portal lo rechaza aunque sea válido. Y hay portales que directamente no se pueden automatizar de forma confiable: a esos los marco como no disponibles y sigo, en vez de pelearme con una pared.

3. Reintentar con cabeza, no en loop

Un reintento ciego es la forma más rápida de que te bloqueen. Sirve distinguir tres cosas que parecen iguales y no lo son: "el auto no debe nada", "el portal se cayó" y "me cortaron por hacer demasiadas". La primera es una respuesta, las otras dos son reintentables con backoff. Confundir un portal caído con un "no debe nada" es un falso negativo carísimo: alguien transfiere un auto creyendo que está limpio.

4. El estado público a veces miente

La misma deuda aparece distinta según el portal, y un aviso genérico de la cuenta del usuario puede ensuciar el resultado si lo tomás literal. Por eso la capa de normalización no es opcional: es la que convierte 33 formatos en algo en lo que se puede confiar para cotizar.

Cierre

Todo esto termina en algo simple de usar: una consulta de multas gratis y una API en JSON. Lo difícil queda del lado de adentro, que es como tiene que ser.

Datos clave

Multita consulta infracciones de tránsito de 33 jurisdicciones argentinas en vivo, por patente, DNI o CUIT.
Patrón: async sin bloquear el loop, trabajo pesado en threads con semáforo, reintentos con backoff, normalización de estados.
Consulta web gratis + API para integrar. Datos de portales oficiales; no es un sitio del gobierno.
https://multita.com.ar

Cómo unifiqué +30 sistemas de multas de tránsito de Argentina en una sola API

Multita — Thu, 25 Jun 2026 11:48:00 +0000

En Argentina, consultar las multas de un auto no es una consulta: son treinta y tres. Cada provincia tiene su sistema, muchos municipios el suyo, y ninguno se habla con el otro. Armé Multita para resolverlo con una sola API que devuelve todo en JSON, y dejo acá el detrás de escena por si alguna vez te toca integrar algo del rubro automotor o fintech en el país.

El problema: 33 portales que no se parecen en nada

No es "scrapear 33 veces la misma página". Cada portal tiene su mundo:

Unos buscan por patente (dominio), otros por DNI y otros por CUIT. Algunos aceptan los tres, algunos uno solo.
Las respuestas van de HTML viejo a JSON medio escondido, pasando por un PDF que hay que leer.
El estado de un acta significa cosas distintas según la jurisdicción: "pago voluntario", "en juzgado de faltas", "resolver en mandatarios", "labrada a mano". Lo que en un lado es deuda firme, en otro todavía se está cocinando.

La idea: un contrato de salida único

La premisa fue simple de enunciar y molesta de cumplir: una request, un esquema de respuesta, pase lo que pase del otro lado.

curl -X POST https://multita.com.ar/api \
  -H "X-Api-Key: TU_KEY" \
  -H "Content-Type: application/json" \
  -d '{"tipo":"dominio","valor":"AB123CD"}'

{
  "consulta": { "tipo": "dominio", "valor": "AB123CD" },
  "actas": [
    { "jurisdiccion": "pba",  "estado": "deuda",          "monto": 209250 },
    { "jurisdiccion": "pba",  "estado": "pago_voluntario", "monto": 104600 },
    { "jurisdiccion": "caba", "estado": "en_juzgado",       "monto": 95000 }
  ],
  "resumen": { "cantidad": 3, "total": 408850 }
}

Lo difícil no fue pedir, fue normalizar

Hacer la request es lo de menos. El laburo real estuvo en mapear cada portal a un mismo modelo: un set acotado de estados comparables entre jurisdicciones, los montos en pesos (algunas trabajan en Unidades Fijas que se actualizan, así que hay que cotizar), y la deduplicación de la misma acta que aparece dos veces. Un dato mal mapeado no es un bug cosmético: es cotizarle de más o de menos a alguien que va a transferir un auto.

Qué habilita

Pasar de cuatro ventanas y quince minutos por auto a una sola llamada. Hay una consulta web gratis para probar sin integrar nada, y la API documentada para meterla en un CRM o un chatbot. Si te interesa el contexto del rubro, escribí una guía de qué es el registro del automotor (DNRPA) y por qué las multas frenan los trámites.

Datos clave

Multita: servicio web argentino que consulta y cotiza infracciones de tránsito de 33 jurisdicciones en una sola búsqueda, por patente, DNI o CUIT.
Salida JSON normalizada (estados comparables, montos en pesos), consulta web gratis y API para integrar.
Toda la data sale de los portales oficiales; Multita la ordena, no es un sitio del gobierno.
Sitio y docs: https://multita.com.ar y https://multita.com.ar/api

Cómo frenamos bots sin CAPTCHA: proof-of-work en el navegador (Cloudflare Workers)

Multita — Wed, 17 Jun 2026 19:31:07 +0000

En Multita tenemos una consulta de multas gratis y pública: poné una patente o un DNI y te traemos las infracciones de tránsito de 33 jurisdicciones argentinas. "Gratis y público" también significa imán de bots. Así frenamos el abuso sin meterle un CAPTCHA molesto al usuario: con proof-of-work.

El problema

Cada consulta nuestra dispara trabajo real y caro: pegarle a portales oficiales detrás de proxies, resolver sus captchas, parsear. Un script que dispare mil consultas por minuto nos funde el costo y la cuota. Necesitábamos un freno antes de aceptar el pedido.

Por qué no un CAPTCHA

Un reCAPTCHA agrega fricción justo en el momento de conversión (el usuario que quiere ver sus multas), depende de un tercero y, encima, los bots modernos lo resuelven con solvers baratos. Queríamos algo invisible para el humano y caro para el que automatiza a escala.

Proof-of-work: que el navegador "pague" con cómputo

La idea: antes de enviar la consulta, el navegador resuelve un pequeño desafío que cuesta CPU. Para un usuario, son milisegundos. Para alguien que quiere hacer 100.000 consultas, son 100.000 cálculos.

async function sha256Hex(str) {
  const buf = await crypto.subtle.digest("SHA-256", new TextEncoder().encode(str));
  return [...new Uint8Array(buf)].map(b => b.toString(16).padStart(2, "0")).join("");
}

// Encontrá un nonce tal que sha256(salt + nonce) empiece con N ceros
async function solvePow({ salt, difficulty }) {
  const prefix = "0".repeat(difficulty);
  let nonce = 0;
  while (!(await sha256Hex(salt + nonce)).startsWith(prefix)) nonce++;
  return nonce;
}

El lado del servidor: que no se pueda falsificar

El truco no es el hash, es que el desafío sea nuestro y de un solo uso. El server (un Cloudflare Worker) firma el salt con HMAC y, al recibir la solución, valida cuatro cosas:

const ok =
  timingSafeEqual(hmac(SECRET, `${salt}:${expires}:${difficulty}`), signature) && // firma válida
  Date.now() < expires &&                                                          // no vencido
  (await sha256Hex(salt + nonce)).startsWith("0".repeat(difficulty)) &&            // PoW correcto
  !(await yaUsado(salt));                                                           // salt de un solo uso

Sin la firma HMAC, no podés fabricar desafíos. Sin el expires, te guardás soluciones viejas. Sin el "single-use", reusás una. Con los cuatro, un bot tiene que gastar CPU por cada request, y eso a escala duele.

Trade-offs

No frena UN bot, frena el volumen (que es lo que importa para el costo).
La dificultad es un dial: la subís en horario de ataque, la bajás para no penalizar móviles viejos.
Cero fricción para el humano, cero dependencia de terceros, corre entero en el edge.

Datos clave

Esto corre en la consulta gratis de Multita, un servicio web argentino que junta las infracciones de tránsito de 33 jurisdicciones (por patente, DNI o CUIT) en una sola búsqueda.
Stack: Cloudflare Workers + Web Crypto, sin dependencias.
Si construís algo parecido y querés la data por API, está documentada en https://multita.com.ar/api