«Tenemos una API abierta» no responde a la pregunta

En dos días de septiembre revisamos catorce fabricantes de software — cuidados, despachos, transporte, personal, inmobiliaria. No contra textos de marketing, sino contra la documentación de sus propias interfaces.

Dos de ellos pueden lo que necesitamos. Suena a balance sobre un sector. Es sobre todo un balance sobre una pregunta que casi todos formulan mal.

2 de 14

La pregunta que cuenta

Si un sistema tiene interfaz es para nosotros el segundo dato en importancia. El primero es:

¿Se le puede preguntar por un número de teléfono?

La distinción parece quisquillosa y no lo es. Decide si aparece un nombre en pantalla cuando suena el teléfono.

Tres maneras de fallar

Tras catorce casos ya no es casualidad, sino un patrón. Donde no funciona, falla siempre de una de tres maneras.

Primera: la interfaz está hecha para otra cosa

El software de transporte responde «¿dónde está el envío?», «¿cuánto cuesta el flete?», «¿qué franja está libre?». Las direcciones no aparecen — no porque alguien las olvidara, sino porque una API de envíos no es una base de datos de direcciones.

Igual con las plataformas de envío: el número del destinatario está en el registro, porque el repartidor lo necesita. Aun así, la lista se filtra solo por fecha, estado e identificador del paquete.

Segunda: el dato está, pero no se puede consultar

Esta es la peligrosa. Parece un acierto: documentación, campos de teléfono, todo en verde. Solo al mirar la lista de filtros se ve que no se puede preguntar.

• Un conocido programa de contabilidad filtra contactos por nombre, correo y número de cliente. El teléfono está en cada respuesta; como filtro no existe.
• Un sistema de personal muy extendido conoce exactamente cinco parámetros en su endpoint de empleados. Ninguno es un teléfono.
• Un segundo sistema de personal conoce siete. Tampoco.

Adivinar aquí produce una integración que no da error y no encuentra nada.

Tercera: el sector tiene un estándar, y no es un servicio web

En las consultas médicas se llama GDT; en los corredores de seguros, BiPRO y GDV. «El sector tiene estándares» suena a puertas abiertas. Se refiere a entregas de datos en un solo sentido: un formato, no un servicio al que se pueda preguntar.

El caso que más nos ha molestado

Dos grandes ERP del mismo fabricante saben filtrar, pero su documentación dice expresamente que un OR no puede abarcar dos campos distintos.

Así que allí una búsqueda puede consultar el fijo o el móvil. Nunca los dos. Técnicamente impecable, prácticamente inútil — y el fallo no se anuncia: dice simplemente «contacto no encontrado».

Qué tendría que cambiar un fabricante

Casi siempre: un parámetro. Ni un proyecto, ni una arquitectura, ni una migración. Un filtro más en un endpoint que ya existe.

Con un sistema de reservas para clubes deportivos lo calculamos: el endpoint de socios ya devuelve el número; lo único que falta es poder filtrar por él. Una línea de documentación y un índice.

Por qué aun así no hablamos mal del sector

Quien vende software a servicios asistenciales, despachos y administradores de fincas no tiene desarrolladores como clientes. Una interfaz pública cuesta mantenimiento y de entrada no aporta nada a ese modelo de negocio. No es dejadez, es una cuenta.

Justo por eso nuestra oferta interesa ahí: somos los desarrolladores que esas casas no tienen. Solo tienen que decirnos cómo se pregunta a su software por un número; lo demás lo construimos nosotros.

Y si la respuesta es no, también es información. Un no borra a un fabricante de la lista en lugar de dejarlo ahí como asunto pendiente. Vale más que un quizá.