La API y la web oficial no coinciden: cómo investigar la diferencia
Dos interfaces del mismo organismo pueden usar filtros, tiempos y estados distintos. Una comparación controlada evita declarar que una está equivocada sin evidencia.
Por Marco Ferreiro ·
Una API devuelve tres actas y la web oficial muestra cuatro. O la web aparece vacía mientras la integración conserva una infracción. La reacción rápida suele ser elegir una interfaz como “verdad” y descartar la otra. Esa decisión es débil si antes no igualamos alcance, momento y filtros.
Dos pantallas con el mismo logo pueden ser productos diferentes. Investigar la brecha exige tratar cada ejecución como evidencia, no como una captura aislada.
Primero: confirmar que son fuentes autorizadas
La comparación sólo tiene sentido entre interfaces oficiales o documentadas. Una URL parecida, un resultado reenviado por un tercero o un endpoint descubierto sin autorización no se incorpora como referencia.
Guardamos dominio, documentación, condiciones de uso y responsable publicado. En SINAI, por ejemplo, las condiciones aclaran que las jurisdicciones adheridas son responsables de cargar y actualizar sus datos. Ese detalle impide suponer que toda novedad aparece al mismo tiempo.
Si una API no es pública, no se la prueba mediante ingeniería inversa. Se solicita documentación o se trabaja con el canal autorizado.
Construir un caso comparable
Antes de ejecutar, fijamos:
- identificador de prueba autorizado;
- jurisdicción y tipo de búsqueda;
- instante o ventana máxima entre consultas;
- credenciales y alcance de la API;
- filtros visibles y predeterminados;
- zona horaria;
- versión o revisión informada;
- cantidad de páginas solicitadas.
Usar una patente en la web y un documento en la API no es el mismo caso. Tampoco lo es comparar “pendientes” con “todas”, aunque ambas interfaces parezcan mostrar multas.
Los casos publicados son sintéticos o propios y se redactan. No compartimos tokens, payloads personales ni actas reales.
El tiempo entre ambas consultas importa
Una jurisdicción puede cargar, corregir o dar de baja un acta entre dos ejecuciones. Para reducir esa causa, consultamos en una ventana corta y registramos la hora del servidor cuando existe.
No forzamos simultaneidad con múltiples llamadas agresivas. Respetamos límites y términos. Si el portal usa un proceso asincrónico, registramos cuándo empezó y cuándo terminó, no sólo cuándo se abrió la página.
Una diferencia que desaparece al repetir minutos después se clasifica como posible desfase de actualización. No se borra el primer resultado: forma parte de la evidencia.
Alcance declarado y cobertura efectiva
La web puede consultar sólo jurisdicciones adheridas; la API, un subconjunto contratado; o a la inversa. La primera columna de la matriz no es “cantidad de multas”, sino fuentes incluidas.
Para cada interfaz anotamos:
- organismos consultados;
- fuentes omitidas o no disponibles;
- búsqueda por dominio o persona;
- estados incluidos;
- período, si existe;
- cobertura geográfica;
- resultado parcial informado.
Si la interfaz no declara el alcance, se marca “no documentado”. No se completa a partir del aspecto visual.
Los filtros invisibles producen diferencias visibles
Una web puede ocultar actas pagadas por defecto, agrupar duplicados o mostrar sólo las que requieren acción. Una API puede entregar todos los estados y dejar el filtrado al cliente.
Revisamos parámetros, valores predeterminados y controles de la pantalla. También observamos si la web permite expandir una sección o cambiar de pestaña. La frase “la web muestra cuatro” debe indicar en qué vista y con qué opción.
En la API guardamos la solicitud saneada, el status, cabeceras relevantes y el esquema de la respuesta. El código 200 no elimina la posibilidad de un resultado paginado o parcial.
Paginación, límites y cursores
Una causa frecuente es leer sólo la primera página. Verificamos total informado, next, cursor o encabezados documentados. Si hay diez resultados pero el límite es cinco, comparar esa página con una web completa produce una discrepancia artificial.
No inventamos el siguiente cursor ni aumentamos límites fuera del contrato. Recorremos hasta el final documentado y registramos cuántas páginas completamos.
Si el cursor vence o una página falla, el conjunto queda parcial. Reintentar desde cero puede mezclar un snapshot nuevo; la API debe indicar cómo continuar de manera consistente.
Normalización de estados
“Pendiente”, “vigente”, “a resolver” y “en juzgamiento” no son sinónimos automáticos. Construimos una tabla que conserva el valor original y, por separado, la categoría interna.
La comparación se hace primero por identidad de acta y estado crudo. Recién después se analiza la normalización. Si dos interfaces usan identificadores diferentes, combinamos organismo, número, fecha, lugar y conducta con reglas prudentes.
Una coincidencia aproximada no se fusiona en silencio. Puede haber dos hechos parecidos.
Un ejemplo sintético
La API ficticia devuelve actas A, B y C. La web muestra A, B, C y D. La matriz revela que la API fue llamada con status=pending, mientras D figura “en revisión”. Al quitar el filtro, ambas devuelven cuatro.
En otro caso, la API informa total cuatro y entrega dos elementos más un cursor. El cliente no siguió el cursor. El problema no estaba en la fuente oficial, sino en el consumidor.
Un tercer caso permanece sin explicación: mismos filtros y hora, pero una acta sólo aparece en la web. El resultado se reporta como discrepancia abierta con evidencia de ambos lados.
Comparar estructura y significado
OpenAPI permite documentar operaciones, parámetros y respuestas. Esa descripción reduce conjeturas, pero no garantiza que la implementación y la documentación estén sincronizadas.
Validamos el payload contra la versión esperada y conservamos campos desconocidos para diagnóstico. Un valor ausente no se convierte en cero. Un arreglo vacío no se interpreta igual que una fuente fallida si el contrato distingue esos estados.
En la web, registramos texto de cobertura y mensajes de error, sin automatizar accesos prohibidos ni almacenar datos de terceros.
Cómo informar la diferencia
El reporte debería incluir:
- identidad de ambas interfaces;
- instante y duración;
- parámetros y filtros;
- cobertura declarada;
- paginación completada;
- conjunto por identidad y estado;
- hipótesis comprobadas;
- diferencias sin resolver.
No publicamos “la API está mal” sólo porque tiene menos filas. Decimos, por ejemplo: “la API documentada no incluyó un estado que la web mostraba a las 10:04; la causa no pudo aislarse”.
Regla operativa mientras se investiga
Una discrepancia no habilita a responder “sin multas”. El sistema conserva el resultado más cauteloso como asunto pendiente y comunica qué fuente no pudo reconciliarse.
Tampoco suma importes de ambos conjuntos sin deduplicación. La evidencia queda separada por procedencia y la resolución se hace con el organismo.
El objetivo no es que API y web siempre se vean iguales. Es poder explicar cuándo difieren por filtros, actualización o cobertura, y reconocer con honestidad cuándo todavía no hay explicación verificable.
Metodología
- Alcance
- Matriz de comparación para una API documentada y una web oficial usando casos sintéticos o propios autorizados.
- Unidad de análisis
- Una ejecución identificada por interfaz, versión, instante, parámetros, alcance, estado y conjunto de resultados.
- Cobertura
- Documentación oficial de SINAI, Datos Argentina, OpenAPI y HTTP consultada el 14 de agosto de 2026.
Limitaciones
- No todas las webs exponen una API pública ni autorizan automatización; el método sólo usa accesos documentados.
- Una observación puntual no permite inferir cuál interfaz se actualizará primero en casos futuros.
Fuentes
- Términos y condiciones de la consulta de infracciones SINAI — Agencia Nacional de Seguridad Vial (consultada el )
- Consulta de infracciones SINAI — Agencia Nacional de Seguridad Vial (consultada el )
- Documentación y recursos de la API de Series de Tiempo — Jefatura de Gabinete de Ministros (consultada el )
- OpenAPI Specification 3.2.0 — OpenAPI Initiative (consultada el )
- RFC 9110 — HTTP Semantics — RFC Editor (consultada el )
Preguntas frecuentes
¿La web siempre tiene prioridad sobre la API?
No necesariamente. Cada interfaz puede tener alcance y tiempos distintos. La referencia es la documentación vigente del organismo y la evidencia de cada consulta.
¿Conviene unir los resultados de ambas interfaces?
Sólo con reglas explícitas de identidad y procedencia. Una unión ciega puede duplicar la misma acta o combinar estados incompatibles.
¿Una respuesta 200 significa que la consulta fue completa?
No. El estado HTTP confirma una respuesta exitosa según el endpoint, pero la completitud depende de cobertura, paginación, filtros y estado de las fuentes subyacentes.
Notas relacionadas
De fuente oficial a resultado: el recorrido de una consulta en multas.ar
Entre ingresar una patente y mostrar un resultado hay decisiones sobre alcance, respuesta de cada fuente, normalización y trazabilidad. Documentarlas evita que un error parezca un cero.
Cobertura de una API: cómo comunicar fuentes caídas y resultados parciales
Una integración de infracciones necesita informar qué fuentes respondió, cuáles fallaron y si el resultado es completo. Un cero sin cobertura comprobada puede inducir decisiones incorrectas.
Timeout no significa “sin multas”: cómo informar resultados parciales en una integración
Cuando una fuente no responde, el resultado es parcial o indeterminado, nunca cero. Un contrato explícito permite reintentar, alertar y decidir sin producir falsos negativos.