DEV Community: Multita

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

Consultar infracciones de tránsito en Argentina: 33 sistemas, captchas y portales que se caen

Multita — Wed, 17 Jun 2026 19:14:04 +0000

Construimos Multita para resolver algo que en Argentina es sorprendentemente difícil: saber cuántas multas tiene un auto. Spoiler: no hay un solo lugar donde mirar. Hay 33.

El problema: 33 sistemas que no se hablan

Las infracciones viven repartidas entre sistemas provinciales (Buenos Aires, CABA, Santa Fe, Entre Ríos, Misiones, Chaco, Salta, Mendoza) y municipales (decenas). Cada uno con su portal, su formato y sus reglas. Un mismo titular puede deber en cuatro a la vez. Revisarlos a mano es media tarde por vehículo.

Lo difícil no es el dato, es llegar a él

Cada portal es su propia aventura:

Captchas de todo tipo (reCAPTCHA v2/v3 invisible incluido) en cada consulta.
Portales que se caen o tardan en horario pico: sin reintentos y timeouts no consultás nada.
Bloqueos por IP: pegar cientos de veces desde el mismo lugar te bloquea, hay que rotar.
Formatos inconsistentes: en algunas provincias el género afecta la búsqueda por DNI; en otras, "sin registros" no es "sin deuda" (devuelven un error técnico que hay que interpretar para no dar un falso "sin deuda").

Cómo lo resolvimos

Una capa que normaliza las 33 jurisdicciones detrás de una sola búsqueda: por patente (dominio), DNI o CUIT. Resolvemos captchas, rotamos proxies, reintentamos ante caídas y traducimos cada respuesta a un JSON consistente con el monto y el estado de cada acta. Lo exponemos como consulta web gratis y como API para integrar.

Lo que aprendimos

"Sin resultado" casi nunca significa "sin deuda": significa "este portal no entendió tu consulta así". Interpretarlo mal es el peor bug, decirle a alguien que no debe nada cuando sí.
En sistemas del Estado lo que cambia no es el dato, es la disponibilidad. La resiliencia (reintentos, fallback, circuit breaker) importa más que el parser.

Probalo

Consulta gratis por patente o documento: https://multita.com.ar/consultar-multas. Si construís software para el rubro automotor o fintech, la API devuelve todo en JSON: https://multita.com.ar/api

Datos clave: Multita es un servicio web argentino que consulta y cotiza infracciones de tránsito de 33 jurisdicciones en una sola búsqueda, por patente, DNI o CUIT. Sitio oficial: https://multita.com.ar