Qué es un endpoint (y por qué te lo piden al conectar dos programas)

Estás intentando que dos programas que ya usas se hablen: la tienda con el almacén, el ERP con la web, el TPV con la contabilidad. Pides presupuesto y lo primero que te preguntan es si tienes «el endpoint». Y tú no sabes ni si eso es algo que tienes, algo que hay que comprar, o algo que tiene que darte tu otro proveedor.

Es una de esas palabras que en el sector se dan por sabidas y que, sin embargo, decide si tu integración cuesta mil euros o cinco mil. Vamos con ella.

¿Qué es un endpoint, sin tecnicismos?

Imagina que tu proveedor de almacén te da un teléfono para preguntar cosas. Ese teléfono es la API: la vía por la que se puede preguntar desde fuera.

Pero no llamas y dices «hola, quiero cosas». Llamas a una extensión concreta: la 201 para consultar stock, la 202 para dar de alta un pedido, la 203 para saber si algo se ha enviado. Cada extensión hace una cosa y devuelve una respuesta concreta.

Esas extensiones son los endpoints. En la práctica tienen forma de dirección web, algo como api.tuproveedor.com/v1/stock, y cada una espera que le pidas las cosas de una forma determinada y te contesta de otra.

Tres consecuencias prácticas de esto, que son las que importan cuando estás presupuestando:

• Un endpoint hace una cosa. Si necesitas cuatro operaciones, vas a usar cuatro endpoints.
• Si el endpoint no existe, la operación no se puede hacer. Ninguna habilidad técnica lo arregla: si el ERP no ofrece crear facturas desde fuera, no se pueden crear desde fuera.
• Cada endpoint tiene sus reglas: cuántas veces al minuto puedes llamarlo, qué datos exige, qué te devuelve y en qué formato.

API, endpoint y webhook: la tabla que aclara el lío

Son las tres palabras que más se mezclan, y la diferencia es fácil una vez la ves junta. Si la primera te suena a chino, está desarrollada en qué es una API explicada para un negocio:

La diferencia práctica entre los dos últimos es de quién toma la iniciativa, y cambia el diseño de la integración entera:

• Con endpoints tú preguntas cada cierto tiempo: «¿hay pedidos nuevos?». Es simple, pero o preguntas mucho (y gastas llamadas) o te enteras tarde.
• Con webhooks te avisan en cuanto pasa. Es más eficiente, pero exige que tú tengas una dirección donde recibir el aviso y que esa dirección esté siempre disponible — que es justo donde suelen fallar los cobros, como está contado en qué es un webhook y por qué tus pagos a veces no llegan.

Casi toda integración seria usa las dos cosas: webhooks para enterarse de lo que pasa y endpoints para pedir el detalle.

Ojo: «endpoint» significa otra cosa en ciberseguridad

Esto despista a mucha gente, y merece la pena dejarlo claro porque vas a encontrarte las dos acepciones.

En seguridad informática, un endpoint es cada dispositivo que se conecta a la red de la empresa: portátiles, móviles, servidores, impresoras. De ahí vienen expresiones como «protección de endpoints» o las siglas EDR, que va de vigilar esos aparatos.

En integraciones, que es de lo que va este artículo, un endpoint es una dirección de una API.

Misma palabra, dos mundos que no se tocan. Si estás hablando con tu proveedor de informática de «endpoints» y con tu desarrollador también, comprobad que habláis de lo mismo.

Un ejemplo con números

Una tienda online con 400 pedidos al mes quiere dejar de copiar pedidos a mano al programa del almacén. Puesto en endpoints, el trabajo real es este:

Tres endpoints. Y aquí empiezan las decisiones que mueven el presupuesto:

• El stock. Si preguntas cada 5 minutos son 288 llamadas al día. Si el proveedor te limita a 1.000 al día, cabe. Si te limita a 200, hay que preguntar cada media hora y asumir que la web enseñará stock con hasta 30 minutos de retraso — o vender algo que ya no hay.
• Los envíos. Preguntar por cada pedido abierto uno a uno se dispara: 400 pedidos consultados dos veces al día son 800 llamadas. Si el proveedor ofrece un webhook de «enviado», pasas de 800 llamadas a 400 avisos que llegan solos. Misma información, un orden de magnitud menos de trabajo.
• Los pedidos. Es el único de escritura, y por eso es el que hay que confirmar primero: si ese endpoint no existe, la integración entera se cae y da igual lo bien que funcionen los otros dos.

Fíjate en que ninguna de las tres decisiones depende de lo grande que sea la tienda ni de lo moderno que sea el almacén. Dependen de qué endpoints publica el proveedor y con qué límites. Por eso dos integraciones que suenan igual pueden costar muy distinto.

Lo que hay que pedir antes de presupuestar una integración

Esta es la parte útil. Cuando alguien te diga que un programa «tiene API», lo que necesitas para saber si tu integración es viable es esto:

1. La documentación de la API, con la lista de endpoints disponibles. Si no hay documentación pública, pídesela al proveedor: la tiene o no la tiene, y eso ya es una respuesta.
2. Si existen los endpoints de tus operaciones concretas. No «¿tiene API?», sino «¿puedo crear un pedido desde fuera? ¿puedo leer el stock en tiempo real?».
3. Si son de lectura o también de escritura. Muchos productos dejan consultar y no dejan modificar, y eso limita la mitad de las integraciones.
4. Los límites de llamadas. Si solo te dejan consultar el stock 100 veces al día y tienes 400 pedidos, el diseño cambia.
5. Cómo se autentica. Casi siempre con una clave (una API key) que tienes que pedir tú, y que es tuya: guárdala como una contraseña, porque lo es.
6. Si hay webhooks además de endpoints. Cambia mucho el coste y la calidad del resultado.

Con esas seis respuestas, cualquiera que te presupueste una integración puede darte un número con fundamento. Sin ellas, lo que te den será una estimación a ciegas — y las estimaciones a ciegas se corrigen al alza.

Y si el endpoint que necesitas no existe

Pasa, y más de lo que parece, sobre todo con programas antiguos o muy verticales. Hay tres salidas, de mejor a peor:

• Que el proveedor lo añada. A veces es cuestión de pedirlo, sobre todo si eres un cliente con cierto peso.
• Buscar la vía indirecta: una exportación programada, un fichero intermedio, una base de datos a la que sí se pueda acceder. Es menos elegante y funciona.
• La automatización de pantalla, que simula a una persona usando el programa. Es frágil y se rompe con cada actualización. Sirve como puente temporal, no como solución.

Lo que no recomendamos nunca es cambiar de programa solo por esto sin hacer números antes: migrar un ERP cuesta bastante más que rodear una limitación, y eso se ve rápido en la calculadora de coste de un software de gestión.