Empezar por la pregunta correcta
Una consulta vehicular puede responder preguntas distintas: si una fuente registra multas, qué información ofrece sobre una inspección o si publica una campaña de revisión. Antes de elegir una integración, conviene escribir la pregunta de negocio con precisión. «Conocer el estado del vehículo» es demasiado amplio para definir qué dato falta y cuándo una respuesta resulta suficiente.
Para un equipo de operaciones, esa precisión se traduce en una pantalla más clara. Cada dato necesita un nombre comprensible, su fuente y una explicación de lo que permite concluir. Un resultado técnico correcto puede producir una decisión equivocada si la interfaz le atribuye un alcance mayor.
Separar consulta, observación y vigencia
La hora de la llamada no siempre coincide con la actualización de la información consultada. También puede existir una fecha propia del documento o registro. Conviene conservar esas referencias por separado, cuando la fuente las proporciona, y evitar presentar una fecha desconocida como si fuera reciente.
Una política de actualización debe depender del uso. Revisar un dato para preparar una tarea y comprobarlo antes de una operación son momentos diferentes. El producto puede mostrar cuándo se obtuvo la observación y ofrecer una nueva consulta cuando el proceso lo justifique, sin prometer que una fuente externa se actualiza continuamente.
Un resultado vacío necesita contexto
Una lista vacía puede ser una respuesta válida de una fuente consultada correctamente. También puede aparecer en una integración defectuosa que perdió contenido, interpretó mal una pantalla o recibió una respuesta incompleta. Por eso, «sin registros informados» y «no se pudo completar la consulta» deben producir estados distintos.
La cobertura importa tanto como el resultado. Consultar una jurisdicción no demuestra ausencia de registros en todas las demás. En una vista agregada, conviene conservar qué fuentes respondieron, cuáles quedaron pendientes y si el resultado es parcial. La falta de información nunca debería convertirse silenciosamente en cero.
Conservar el significado de cada producto
VTV y RTO no deben fusionarse automáticamente en un único campo de «inspección aprobada». Son etiquetas que pueden corresponder a registros y alcances diferentes. Una integración debe conservar el tipo de observación y explicar qué informa la fuente, sin deducir equivalencias normativas.
La misma disciplina sirve para multas, recalls y grabado de autopartes. Una campaña publicada no prueba por sí sola que una unidad esté afectada o reparada. Un registro ausente tampoco describe automáticamente una situación de incumplimiento.
Diseñar una revisión que se pueda repetir
Antes de integrar, revisá ejemplos completos, parciales, vacíos y fallidos. Comprobá si tu aplicación conserva identificadores, fechas y estados sin modificar su significado. Definí qué casos se muestran al usuario, cuáles requieren otra consulta y cuáles necesitan revisión humana.
Estas decisiones forman parte del diseño del producto, no de una promesa de cobertura. La ficha de cada API debe permitir entender su alcance; una evaluación concreta de la fuente determina si sirve para el proceso que querés construir.