DEV Community: Multita

La UF de CABA subió 23,5% de golpe: por qué un valor semestral es más peligroso de cachear

Multita — Wed, 02 Sep 2026 05:06:49 +0000

El 2 de septiembre de 2026 la Unidad Fija de la Ciudad de Buenos Aires pasó de $949,99 a $1.173,08. Un 23,5% de una sola vez. El día anterior, la Provincia de Buenos Aires había movido la suya un 0,44%.

Los dos valores miden lo mismo: el precio de la nafta de mayor octanaje. Los dos definen cuánto sale una multa de tránsito. Y sin embargo uno saltó cincuenta veces más que el otro.

La diferencia no es económica, es de calendario. Y si te tocó alguna vez sincronizar un valor oficial que publica un tercero, ahí hay una trampa que vale la pena mirar de cerca.

Los dos relojes

Provincia de Buenos Aires: la UF equivale a un litro de nafta premium y se ajusta cada dos meses. Sus últimos saltos: +2,53% en julio, +0,44% en septiembre.
CABA: la UF equivale a medio litro y la fija el Instituto de Estadística de la Ciudad cada seis meses (Ley 451, art. 20). Sus últimos saltos: +19,0% en marzo, +23,5% en septiembre.

Misma variable de fondo, misma inflación, resultados completamente distintos en la pantalla. Uno reparte el aumento en pedacitos, el otro lo acumula y lo suelta entero.

Por qué esto importa si lo tenés cacheado

Acá está el punto que me interesa.

Supongamos que guardás los dos valores con la misma política. Un TTL de seis horas, un scraper diario, un fallback al último valor conocido si la fuente no responde. Suena razonable y es lo que casi todos hacemos.

El problema es que el costo de servir un dato viejo no es el mismo para los dos.

Si tu copia de la UF bonaerense se queda vieja un bimestre entero, mostrás un número con un 0,44% de error. Nadie se entera, y si se entera no le cambia la decisión.

Si tu copia de la UF porteña se queda vieja un solo día, el 2 de septiembre, mostrás un número con un 23,5% de error. Sobre la multa más cara de la Ciudad eso son $892.360 de diferencia en una sola acta.

Mismo sistema, misma política de caché, mismo tipo de dato. Dos órdenes de magnitud de diferencia en el daño.

La conclusión es incómoda para el instinto de ingeniería, que tiende a tratar uniforme lo que tiene la misma forma:

La frecuencia de actualización de un valor y su volatilidad por actualización están inversamente correlacionadas. Cuanto menos seguido cambia algo, más grande es el salto cuando cambia. Así que "cambia poco" no significa "es seguro cachearlo": puede significar exactamente lo contrario.

Lo que cambia en la práctica

Lo que sacamos de esto no fue bajar el TTL a todo, que es la respuesta perezosa y encima te tira la fuente abajo a pedradas.

Fue empezar a guardar la ventana de validez junto con el valor.

El dato oficial de CABA no viene solo. Viene con las fechas: rige del 2 de septiembre de 2026 al 1 de marzo de 2027. Esa segunda fecha es tan dato como el número, y es la que convierte una pregunta difícil en una comparación trivial.

// Antes: "¿estará viejo?" es una corazonada.
const uf = await cache.get('uf:caba');

// Después: la propia fuente te dice hasta cuándo vale.
const uf = await cache.get('uf:caba');   // { valor, desde, hasta }
if (uf && Date.now() > Date.parse(uf.hasta)) {
  // no adivines: sabés que caducó
  await revalidar('caba');
}

Con eso, el 2 de septiembre no dependés de que el scraper haya corrido a tiempo ni de que alguien se acuerde: el valor guardado se declara vencido solo. Y lo mismo aplica a un valor bimestral, salvo que ahí la ventana es más corta y el riesgo de equivocarse, mucho menor.

El corolario práctico, para cualquier dato oficial de este tipo (una tasa, un índice, un valor de referencia legal): si la fuente publica una fecha de vigencia, guardala. Es la diferencia entre revalidar por reloj y revalidar por contrato.

La otra mitad: qué hacés cuando sí caducó

Que el sistema sepa que el dato venció no significa que pueda conseguir el nuevo. La fuente puede no haberlo publicado todavía, o estar caída, o cambiar el HTML justo ese día.

Ahí el orden de preferencia que nos quedó es:

Valor vivo validado. Si responde y pasa las validaciones (que sea un número, que sea positivo, que no se haya movido un 900% de golpe), ese.
Último valor conocido, marcado como vencido. Se sigue mostrando, porque un número de hace un semestre es infinitamente más útil que un guion, pero el sistema sabe que está en deuda y lo reintenta.
Nunca un vacío.

Y una validación que suena paranoica hasta que la necesitás: acotar el salto. Un ajuste del 23,5% es real y tiene que pasar. Uno del 2.300% es un scraper leyendo mal un separador de miles. La diferencia entre los dos es un if, y de un lado de ese if está publicar montos equivocados en una página que la gente usa para decidir si paga una multa.

Datos, por si llegaste buscando el número

	Valor de 1 UF	Cada cuánto se ajusta	Último salto
CABA	$1.173,08 (2-sep-2026 al 1-mar-2027)	Semestral	+23,5%
Provincia de Buenos Aires	$2.281 (septiembre-octubre 2026)	Bimestral	+0,44%

Un detalle lindo que salió de mirar los dos juntos: como la UF porteña es medio litro y la bonaerense un litro, la primera debería rondar la mitad de la segunda. Antes del ajuste estaba en el 41,6% de la de Provincia, o sea atrasada. Después quedó en el 51,4%. El salto del 23,5% no fue un aumento por encima de la inflación: fue ponerse al día de golpe.

El desglose con los montos por infracción está en el aumento de multas en CABA, y el de Provincia en su propia nota.
Si querés el concepto desde cero, qué es la Unidad Fija lo explica con el histórico de las dos jurisdicciones.
Todo esto sale de Multita, que consulta infracciones en 32 jurisdicciones argentinas. Si lo tuyo es integrarlo, la API las devuelve en JSON con cada acta ya convertida a pesos al valor de UF vigente de su jurisdicción, que es precisamente el problema de este post resuelto del lado del servidor.

Si tenés un valor oficial cacheado en algún lado, andá a fijarte si guardás su fecha de vencimiento. Si no la guardás, tu sistema no sabe que el dato venció: se está enterando cuando alguien se queja.

Valor de la UF en septiembre de 2026: subió a $2.281, y cómo evitamos que el dato quede viejo

Multita — Tue, 01 Sep 2026 21:37:24 +0000

La Unidad Fija (UF), el número con el que se calculan todas las multas de tránsito en la Provincia de Buenos Aires, pasó a $2.281 en septiembre de 2026. Venía de $2.271 en el bimestre julio-agosto: una suba del 0,44%, bastante menor que el 2,53% del ajuste anterior. En la Ciudad de Buenos Aires no se movió, sigue en $949,99, porque allá el ajuste es semestral y no bimestral.

Ese es el dato que la gente busca. Y es, exactamente, el dato que se nos quedaba viejo en medio sitio cada dos meses.

Este post cuenta cómo lo resolvimos, porque el problema es más general de lo que parece: un valor oficial, publicado por un tercero, que cambia en una fecha que no controlás y sin avisarte. Si alguna vez publicaste un precio de dólar, una tasa, un índice de inflación o un valor de referencia legal, es el mismo problema.

Por qué una multa no está en pesos

En Argentina una infracción de tránsito no se expresa en un monto fijo. Se expresa en Unidades Fijas. La norma dice que una infracción vale una cantidad de UF, y aparte, otro organismo fija cuánto vale una UF.

monto = cantidad_de_UF_de_la_infracción * valor_vigente_de_la_UF

En la Provincia de Buenos Aires una UF equivale al precio de un litro de nafta de mayor octanaje, y el Ministerio de Transporte la ajusta cada dos meses. En la Ciudad de Buenos Aires equivale a medio litro, la fija el Instituto de Estadística de la Ciudad y el ajuste es semestral. Dos fuentes, dos ritmos, cero webhooks.

La consecuencia de producto es fuerte: el monto de una deuda no se puede guardar. Hay que recalcularlo cada vez, con el valor vigente. Una multa del año pasado vale más hoy sin que nadie haya hecho nada.

Y la consecuencia técnica es este post.

El estado inicial, que es el estado de casi todos

El número arrancó donde arrancan todos los números: escrito en el lugar donde hacía falta. Un artículo decía "la UF vale $2.271". Otro también. La calculadora tenía su constante. La página de valores tenía la suya.

Trece lugares. Ninguno sabía de los otros.

Mientras el valor no cambia, esto no duele. El problema es que cambia cada dos meses, y actualizar trece archivos a mano tiene una tasa de éxito que no es 100%. Nunca es 100%. Lo que pasa en la práctica es que actualizás los tres que te acordás, los que salen primero en la búsqueda, y los otros diez siguen mostrando el valor del bimestre pasado.

Ahí el costo deja de ser técnico. Un sitio que publica cifras oficiales y muestra dos cifras distintas para la misma cosa pierde exactamente lo único que vende, que es que el número sea confiable. Peor todavía cuando buena parte del tráfico viene de gente buscando "cuánto vale la UF", y hoy también de modelos de lenguaje que leen la página y la citan. Un LLM que encuentra dos valores contradictorios en el mismo dominio no elige el correcto: te descarta como fuente.

Capa 1: una sola fuente, aburrida a propósito

Lo primero fue lo obvio. Un módulo, sin dependencias, que exporta los valores y nada más.

// uf.values.mjs
export const UF_PBA = 2281;
export const UF_CABA = 949.99;
export const UF_VIGENTE = 'septiembre 2026';

Dos decisiones chicas que después valieron mucho:

Es .mjs, no .ts. Porque lo tiene que importar el sitio, pero también el archivo de configuración del build, que corre en Node antes de que exista cualquier transpilación. Un .ts ahí obliga a un paso extra o a duplicar el valor, que es justo lo que estábamos sacando.

No tiene lógica de negocio. Es un archivo que se puede abrir, leer en tres segundos y editar sin entender el resto del sistema. Cuando el Estado publique el próximo ajuste, la tarea es cambiar dos números. Si para actualizar la UF hay que entender la arquitectura, alguien la va a actualizar mal.

Capa 2: tokens que se resuelven en el build

La parte difícil no era el código, era el contenido. Los artículos son Markdown. No pueden importar un módulo.

La solución fue meter tokens en el texto y resolverlos como paso del build:

A {{uf:vigente}} la UF de Provincia quedó en **{{uf:pba}}**.
La multa más cara, de 1.000 UF, llega a {{uf:pba*1000}}.

El resolver es un par de líneas, y la única gracia es que soporta multiplicación, porque la mitad de las menciones en los textos no son "el valor de la UF" sino "cuánto sale una infracción de 300 UF":

export function resolveUfToken(expr) {
  const e = String(expr || '').trim();
  if (e === 'vigente') return UF_VIGENTE;

  const m = /^(pba|caba)(?:\s*\*\s*(\d+(?:[.,]\d+)?))?$/.exec(e);
  if (!m) return null;                    // null = token inválido, ver capa 3

  const base = m[1] === 'pba' ? UF_PBA : UF_CABA;
  const mult = m[2] ? Number(m[2].replace(',', '.')) : 1;
  if (!Number.isFinite(mult) || mult <= 0) return null;

  return formatearPesos(base * mult);
}

Se engancha como integración del build, que en Astro es un hook, pero el patrón es el mismo en cualquier generador estático: interceptar el contenido antes de que se escriba el HTML.

Ahora actualizar la UF es editar dos números. Los 151 tokens repartidos en 16 archivos se resuelven solos.

Capa 3: la que importa de verdad

Acá está la parte que quiero dejar escrita, porque es la que se suele omitir.

Cuando armás un sistema de sustitución, el modo de falla no es que el número salga mal. El modo de falla es que salga {{uf:pba}}. Un token crudo, publicado, en la página que la gente lee y que los buscadores indexan. Es peor que el valor viejo: el valor viejo se ve como un error de actualización, el token crudo se ve como un sitio roto.

Un typo alcanza. {{uf:pva}} en lugar de {{uf:pba}}. El regex no matchea, el reemplazo no ocurre, y si tu resolver es tolerante devolvés el string original y lo publicás.

Por eso el resolver devuelve null en vez de devolver el token, y por eso el build falla:

const malos = [];
// ...por cada archivo, por cada token:
const resuelto = resolveUfToken(expr);
if (resuelto === null) malos.push(`${archivo}: token inválido ${match}`);

if (malos.length) {
  throw new Error(`Tokens inválidos: ${malos.length}.`);
}

Y después, una segunda pasada sobre el HTML ya escrito, que es cinturón y tiradores a propósito:

// GUARDIA: que no quede NINGÚN token sin resolver en lo que se sirve
const quedaron = archivosDeSalida.filter((f) => leer(f).includes('{{uf:'));
if (quedaron.length) {
  throw new Error(`Quedaron tokens sin resolver en: ${quedaron.join(', ')}`);
}

Esa segunda pasada parece redundante y no lo es. La primera valida los tokens que encontró. La segunda valida el artefacto que se va a servir, que es lo único que le llega al usuario. Si mañana alguien agrega otra fuente de contenido que no pasa por el mismo pipeline, la primera no la ve y la segunda sí.

La regla, dicha corta: si el dato es público y verificable, un deploy con el dato roto es peor que un deploy que no sale. Que se caiga el build.

Capa 4: que no dependa del deploy

Con todo lo anterior, actualizar la UF todavía requiere que alguien edite el archivo y haga push. Es rápido, pero es una persona en el camino crítico de un dato que cambia solo.

Así que arriba de eso hay una capa viva. Un scraper propio lee los valores oficiales y los deja disponibles en una API interna. El sitio la consulta y sincroniza el valor en el cliente:

Los valores del archivo son el piso: lo que ve el crawler, lo que se pinta en el primer render, lo que queda si todo lo demás falla.
La API es el techo: si responde, el visitante ve el valor de hoy sin esperar un deploy.

La respuesta se cachea, con TTL, en el borde. Y la degradación es lo único que hay que pensar bien:

const pba = Number(data?.pba);
const caba = Number(data?.caba);
if (!(pba > 0) || !(caba > 0)) return error(502);  // dato raro: no lo propagues

Ese chequeo es más importante de lo que parece. Un 0, un null o un string que se cuela desde arriba no rompe nada visiblemente: publica un monto equivocado, que es el peor resultado posible. Es más seguro no actualizar que actualizar con basura. Si la validación no pasa, el sitio se queda con el valor del archivo y nadie se entera.

Sumado, el orden de confianza queda: valor vivo validado, después valor del archivo, después nada. Nunca se llega a "nada".

Lo que me llevo

Un dato que cambia solo no puede vivir en el lugar donde se muestra. No es una cuestión de prolijidad: la actualización manual falla parcialmente, y fallar parcialmente es peor que fallar entero, porque te deja el sitio contradiciéndose consigo mismo.
El sistema de reemplazo necesita un guard que rompa el build. Sin eso cambiaste "dato viejo" por "token crudo".
Validá el dato vivo antes de mostrarlo. Un valor inválido que se propaga es peor que una actualización que no ocurre.
El fallback tiene que ser un valor real, no un vacío. Si la API se cae, la página sigue diciendo un número correcto de hace un bimestre en vez de un guion.

Nada de esto es sofisticado. Es un archivo, un reemplazo en build y dos excepciones. Pero convirtió "actualizar la UF" de una tarea de trece pasos que salía mal en una de dos números que no puede salir mal en silencio.

Los valores, por si llegaste buscando el dato

Bimestre	UF Provincia de Buenos Aires
Mayo-junio 2026	$2.215
Julio-agosto 2026	$2.271
Septiembre-octubre 2026	$2.281

En CABA la UF vale $949,99 y se ajusta por semestre, así que no acompaña estos movimientos.

Con la UF a $2.281, una infracción de 300 UF (cruzar el semáforo en rojo, VTV vencida) sale $684.300, y el tope de 1.000 UF llega a $2.281.000.

El desglose completo, con los montos por tipo de infracción, está en la nota del aumento de septiembre.
Si querés entender la Unidad Fija desde cero, qué es la UF y cómo se calcula lo explica con el histórico, y hay una calculadora de UF a pesos.
Todo esto sale de Multita, que consulta infracciones en 32 jurisdicciones argentinas por patente, DNI o CUIT. Si lo tuyo es integrarlo, la API devuelve las actas en JSON con el monto ya convertido a pesos al valor vigente, que es precisamente el problema que este post describe, resuelto del lado del servidor.

Si tenés un dato oficial de esos que cambian cada tanto y hoy vive en varios lugares de tu repo, el patrón es portable y se implementa en una tarde. La parte que no hay que saltearse es la tercera.

La unidad de cobro es una decisión de arquitectura, no de pricing

Multita — Tue, 25 Aug 2026 02:23:03 +0000

La unidad de cobro de un SaaS que scrapea no es una decisión de pricing. Es una decisión de arquitectura, y se toma antes de escribir el primer scraper, porque después condiciona todo: el caché, los reintentos, el modo asincrónico y hasta el contrato de errores.

Multita consulta infracciones de tránsito en 32 jurisdicciones argentinas (Provincia de Buenos Aires, CABA, provinciales y municipales). Cada una es un portal de gobierno distinto, con su HTML, su captcha y sus caídas. Este es el razonamiento detrás de cómo quedó definida la unidad, y qué obligó a construir.

El problema: N fuentes por consulta, y N es variable

Una consulta por patente puede tocar una jurisdicción o las 32. Hay dos formas obvias de cobrarla, y las dos son malas.

Cobrar por fuente consultada. El precio sube justo cuando el caso es más grande. Para el que integra, el costo se vuelve imposible de presupuestar: no sabe cuánto va a salir una consulta hasta después de hacerla. Y aparece un incentivo horrible, que es pedir menos fuentes de las necesarias para ahorrar, o sea empeorar el dato a propósito.

Cobrar por llamada, sin más. Suena simple hasta que aparecen los reintentos. Si un portal se cae y el sistema reintenta cinco veces, ¿quién paga esos cinco intentos? Si los paga el cliente, está pagando por la inestabilidad de un tercero. Si los paga el proveedor sin haberlo pensado, el margen se lo come la fuente más inestable.

La decisión fue: una llamada cuenta 1, sin importar cuántas jurisdicciones toque ni cuántos reintentos internos haga. Simple de explicar y de presupuestar. Pero esa promesa hay que sostenerla en el código, y ahí es donde se pone interesante.

Lo que esa promesa obliga a construir

1. Un caché que no se cobre

Si el precio es por llamada, el caché deja de ser una optimización y pasa a ser parte del modelo de negocio. En este caso el TTL es de 48 horas y el caché está aislado por organización, no global.

Lo del aislamiento no es un detalle. Son datos de deuda asociados a una patente o a un documento: dos cuentas distintas no pueden compartir nada. Dentro de una misma organización sí se comparte, y ahí el caché rinde de verdad, porque el panel web y la API comparten el mismo: una consulta desde la web deja el dato listo para el bot, y al revés.

La otra mitad es que el cliente sepa qué está recibiendo. Toda respuesta trae el estado del caché:

"cache": {
  "cacheado": true,
  "antiguedad_segundos": 420,
  "antiguedad_texto": "hace 7 min"
}

Con eso, la integración decide sola si le alcanza el dato de hace un rato o si necesita force_refresh: true. Para deuda vencida el dato de ayer sirve perfecto, no cambia minuto a minuto. Para reflejar un pago recién hecho, no.

Un caché sin esa transparencia es una mentira silenciosa. Con ella es una feature.

2. Reintentos que no empeoren el resultado

Cada jurisdicción se reintenta hasta cinco veces, cada intento por una IP distinta de un pool rotativo y, en las que tienen captcha, resolviendo uno nuevo. Todo eso sigue contando como una sola consulta.

Además, cuando una consulta queda incompleta y sobra tiempo dentro del presupuesto del endpoint, se reconsultan solo las jurisdicciones que fallaron. Las que ya salieron bien se leen del caché recién escrito, así que el reintento solo paga el costo de las fallidas.

La regla que hace que esto sea seguro es la que más costó escribir: el reintento se adopta solo si resolvió al menos una jurisdicción y no rompió ninguna que ya estaba bien. Si no mejora, se conserva la respuesta original tal cual. Un reintento que puede empeorar el resultado no es resiliencia, es una lotería.

3. Un camino asincrónico, porque el sincrónico no da

Acá va el dato incómodo, que conviene decir antes de que lo descubra el que integra: una consulta a todas las jurisdicciones sin caché espera a la más lenta. Puede tardar de segundos a un par de minutos.

Ningún chat aguanta eso en una sola request. Así que el camino recomendado para un bot es encolar y avisar:

POST /consulta/async  ->  202 { "job_id": "9f3a1c8e...", "poll_url": "..." }

El cliente responde "estamos consultando" al instante, y cuando el job termina llega un webhook firmado con HMAC (o se pollea el job_id). El campo resultado tiene exactamente la misma forma que la respuesta sincrónica, así que el código que parsea es uno solo.

Decir el peor caso en la documentación es más barato que un ticket de soporte por timeout.

4. Idempotencia, porque los clientes reintentan

Si se cobra por llamada, un reintento del lado del cliente por un timeout de red no puede contar dos veces. Un header opcional alcanza:

Idempotency-Key: <valor único por consulta>

Con eso, el reintento devuelve la respuesta original en vez de disparar una consulta nueva. Es de las cosas más baratas de implementar y de las que más discusiones de facturación evita.

El contrato que sostiene todo lo demás

Nada de lo anterior sirve si el dato no es confiable, y en un producto que agrega fuentes ajenas el riesgo más caro no es el error: es el falso vacío.

Si un portal de gobierno se cae y el sistema devuelve una lista vacía, el que integra la lee como "este auto no debe nada". Es el peor error posible, porque es silencioso y se propaga hasta el cliente final.

Por eso el contrato separa las dos cosas de forma explícita:

{
  "consulta_completa": false,
  "resultados": [
    { "jurisdiccion": "pba",  "ok": true,  "cantidad_actas": 2, "total_oficial": 142000 },
    { "jurisdiccion": "caba", "ok": false, "error": "timeout" }
  ]
}

ok: false significa "no pudimos ver", nunca "no debe". Y consulta_completa es el campo que hay que leer antes de afirmarle a una persona que no tiene deuda. Una jurisdicción caída no es un error HTTP: viene dentro de un 200, en su propio bloque.

Vale la pena la variante fea: hay dos municipios cuyo portal, buscando por documento y sin registros, responde un HTTP 500 en vez de una respuesta vacía. En la realidad operativa ese 500 significa "sin deuda". Se normaliza a cero actas con ok: true, pero solo para esas dos jurisdicciones y solo por documento. Cualquier otro error sigue siendo una falla real. Las normalizaciones de este tipo hay que acotarlas con nombre y apellido, o se convierten en el bug que devuelve falsos negativos en producción.

Lo que se gana cuando la unidad de cobro está bien elegida

Con la unidad definida así, el producto pudo crecer sin rediseñar el modelo. Sobre la misma llamada se apoyaron cosas bastante distintas entre sí: un modo que además de la deuda oficial devuelve el presupuesto ya calculado con el pricing de cada cliente y el PDF con su marca, monitoreo automático de listas de patentes que avisa cuando aparece una multa nueva o cambia el estado de un acta, y generación de recibos y de escritos de descargo.

Ninguna de esas features tuvo que inventar su propia unidad de cobro. Es el beneficio real de haberla decidido temprano: una consulta sigue siendo una consulta, sin importar cuánto producto se le apile encima. La contracara de la decisión, y conviene nombrarla, es que el proveedor absorbe la varianza: si mañana un portal se vuelve tres veces más lento, el costo lo come el proveedor, no el cliente. Ese es exactamente el riesgo que se está vendiendo.

El razonamiento de negocio detrás de todo esto, con la cuenta en horas y en plata, está contado aparte en cuánto le cuesta a una gestoría cotizar un caso.

Si vas a integrar algo parecido

Tres cosas que conviene dejar cerradas antes del primer scraper:

Definí la unidad de cobro primero. Condiciona el caché, los reintentos y el modo asincrónico. Cambiarla después es cambiar el producto.
Hacé explícita la diferencia entre "no hay" y "no pude ver". Es un campo en el JSON y te ahorra el peor tipo de bug.
Documentá el peor caso de latencia. El que integra lo va a encontrar igual; mejor que lo encuentre leyendo.

El contrato completo está en la especificación OpenAPI, y hay una versión en texto plano pensada para pasarle a un asistente en llms-full.txt. La documentación de la API de consulta y cotización tiene los ejemplos completos.

Entity SEO: how sameAs, Wikidata and Crunchbase tell Google your brand is real

Multita — Mon, 10 Aug 2026 12:00:00 +0000

Most SEO advice is about links and keywords. There is a quieter layer that matters more for a young brand: entity SEO, the job of convincing Google (and the AI models reading the same graph) that your brand is one real, identifiable thing. Here is what actually moved the needle for Multita.

sameAs is not a backlink

The common confusion: people think linking out to their own profiles drains authority. sameAs is not that. It lives in your structured data and it is an identity statement, not a vote. It says "these profiles and this domain are the same entity". It passes no PageRank and it costs you nothing.

"sameAs": [
  "https://www.linkedin.com/company/multita/",
  "https://www.crunchbase.com/organization/multita",
  "https://www.wikidata.org/wiki/Q..."
]

Wikidata and Crunchbase: the graph the models read

A Wikidata item and a Crunchbase profile are not big traffic sources. Their value is being structured, trusted nodes about your entity, the kind that get pulled into the Knowledge Graph that Google and AI assistants consult. For a new company with no Wikipedia page yet, they are the most credible "this exists" signal you can plant.

Why it matters for AI answers

When someone asks an assistant about your category, the model names you correctly only if your entity is well defined across these sources. Vague entity, vague or wrong citation. A consistent name, URL and description repeated across your structured data, your Wikidata item and your profiles is what makes the answer land on you.

Entity SEO will not rank a page by itself. It makes everything else you do attach to a brand the machines actually recognize, and for a new site that recognition is worth more than another handful of links.

Getting a brand-new site read by Google and AI: IndexNow, llms.txt and structured data

Multita — Mon, 03 Aug 2026 12:00:00 +0000

A new domain has no authority and no crawl history, so the default is to wait weeks for Google to notice you. You can skip a lot of that wait. When we launched Multita, three cheap and boring pieces did most of the work of getting indexed and getting quoted by AI assistants.

IndexNow: stop waiting for the crawler

IndexNow lets you ping search engines the moment a page changes, instead of waiting to be crawled. You drop a key file at your root and POST the changed URLs. On Cloudflare it is a few lines in a Worker. New pages got picked up in hours, not days.

llms.txt: a map for the models

llms.txt is a plain text file at your root that points AI crawlers at your most useful pages, in clean markdown. It is young as conventions go, but it costs nothing and it tells a model "this is what the site is about" without making it fight your nav and footer to find out.

Structured data: say what you are in a language machines trust

JSON-LD is the part both Google and the models lean on. An Organization and a WebSite block state your name, your URL and what you do, as data instead of guesswork.

<script type="application/ld+json">
{ "@context":"https://schema.org", "@type":"Organization",
  "name":"Multita", "url":"https://multita.com.ar" }
</script>

The payoff is clearer entity recognition, a real shot at a brand panel, and a much higher chance that an AI answer cites you correctly instead of inventing something.

None of this buys authority. It buys legibility, which for a new site is the thing standing between you and being found. Ship all three on launch day.

API design: raw data, or totals with the business logic baked in?

Multita — Mon, 27 Jul 2026 12:00:00 +0000

When you expose a data API you hit this fork fast: do you return raw, normalized records and let the client do the math, or do you return totals with your business logic already applied? We faced it building the API for Multita, which returns the traffic fines on a vehicle, and the answer that held up was "both, on purpose".

The case for raw

Raw, normalized records are honest. Each fine comes back with its amount, status and jurisdiction, and the integrator decides what to do with them. A developer building a dashboard wants exactly this. They have their own rules, and a pre-chewed total just gets in the way.

{
  "items": [
    { "jurisdiction": "pba", "status": "debt", "amount": 209250 },
    { "jurisdiction": "pba", "status": "voluntary_payment", "amount": 104600 }
  ]
}

The case for baked-in totals

Now picture a different integrator: a WhatsApp bot that quotes a client in a single message. It does not want to reimplement your discount rules, your "which fines actually count" logic, or your rounding. It wants a number it can trust. If every integrator re-derives that number, they will all get it a little wrong, each in their own way.

Why we ship both

So the Multita API returns the normalized items plus an optional summary with the totals already computed. Raw for the people who want control, totals for the people who want an answer. The rule we follow is narrow: never force the client to reimplement business logic to get a correct number, and never hide the raw data either.

If you are designing an API, start from who integrates it. A team with its own logic and a bot that just wants the result are different customers, and you can serve both without picking a side.

Construir software para un mercado que los devs ignoran

Multita — Mon, 20 Jul 2026 12:00:00 +0000

Los mejores nichos suelen ser los aburridos. Mientras todos hacen otra app de productividad, hay industrias enteras moviéndose con planillas, PDFs y trámites a mano, esperando que alguien se tome el laburo de entenderlas. Nosotros caímos en una de esas: los trámites del automotor en Argentina.

El nicho que nadie quiere

Acá hay una profesión entera, las gestorías, que vive de hacer transferencias, informes y libre deudas para sus clientes. Parte de su día es revisar las multas de cada auto, porque una multa impaga frena una transferencia y la deuda viaja con el vehículo, no con el dueño anterior. El detalle: esas multas están repartidas en más de 33 sistemas oficiales que no se hablan entre sí.

Ningún dev mira eso. No es sexy, no sale en Hacker News. Y justo por eso la competencia es floja y la demanda es real y constante.

Por qué un mercado ignorado juega a favor

La gente ya tiene el problema y ya paga por resolverlo, hoy con horas de trabajo manual.
La competencia rara vez es técnica, así que un producto que de verdad funcione gana casi solo.
Entender el dominio es la barrera. Una vez que sabés qué es una "denuncia de venta" o por qué un acta que arranca con "01-" no tiene descuento de gestoría, tenés algo que un extraño no copia en un fin de semana.

Eso último es lo importante. En Multita la parte difícil no fue el código, fue aprender las reglas raras de cada jurisdicción y meterlas en el producto. Ese conocimiento es el foso.

Cómo entrar

Hablá con la gente que sufre el problema antes de escribir una línea. Las reglas que te cuenten, las que no están documentadas en ningún lado, son las que hacen que tu producto sea el que funciona y no el que casi funciona.

Si estás buscando qué construir, mirá los rubros que todos evitan por aburridos. Ahí está la demanda sin atender.

Rate limiting de una herramienta pública con Cloudflare KV y D1

Multita — Mon, 13 Jul 2026 11:59:00 +0000

Si tu producto tiene una parte gratis y pública, es cuestión de horas hasta que alguien la quiera exprimir con un script. Nosotros tenemos una consulta de multas gratis que cualquiera usa sin registrarse, así que el rate limiting no era opcional. Lo resolvimos entero en el borde, con Cloudflare KV y D1, sin servidor propio.

Quién hace qué

La división que nos funcionó es simple. KV guarda el contador, porque tiene TTL nativo y lecturas baratas en cada PoP. D1 (SQLite en el borde) guarda lo que sí querés conservar y cruzar después, como los leads del formulario.

const key = `rl:${ip}:${hoy}`;
const usado = parseInt(await env.RATE.get(key) || "0", 10);
if (usado >= LIMITE_DIARIO) return new Response("Probá mañana", { status: 429 });
await env.RATE.put(key, String(usado + 1), { expirationTtl: 86400 });

El TTL de 86400 hace que la clave se borre sola al otro día. No limpiás nada, y el set de claves nunca crece más allá de "gente que consultó hoy".

La trampa de la consistencia

KV es eventualmente consistente, así que entre dos PoP hay una ventanita de un segundo donde alguien podría pasarse del límite. Para frenar abuso eso no me quita el sueño. Si necesitaras un límite estricto, con plata de por medio, ahí conviene un Durable Object, que te da consistencia fuerte a cambio de algo de latencia.

El límite como embudo

Un detalle de producto: el límite no es solo defensa, es conversión. Cuando alguien llega al tope, ese es el momento justo para ofrecerle el plan sin límite. El 429 deja de ser un error y pasa a ser una puerta.

Si vas a abrir algo gratis al público, poné el rate limiting desde el día uno. Sale mucho más barato que sacarte un scraper de encima después.

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