Qué es una API y por qué te la nombran en cada presupuesto

En cada presupuesto de web, tienda o integración aparece la palabra. «Lo conectamos por API». Y ahí se acaba la explicación. Tú firmas, pagas, y tres meses después descubres que la conexión existe pero el stock sigue sin cuadrar, o que el proveedor te pide 4.000 € más porque «el ERP no expone ese dato».

No hace falta que sepas programar para evitar eso. Hace falta que sepas qué preguntar antes de firmar. Eso es lo que hay aquí.

Qué es una API, dicho de forma útil

Una API (Application Programming Interface) es una puerta que un programa deja abierta para que otros programas le pidan cosas o le manden cosas. Nada más.

Tu ERP tiene una puerta. Tu tienda online tiene otra. Tu TPV, tu pasarela de pago, tu agencia de transporte, tu plataforma de email, todos tienen la suya. Cuando alguien dice «lo conectamos por API» está diciendo que va a escribir un programa que llame a esas puertas.

La parte que casi nunca se dice en la reunión: cada puerta tiene su propio portero, sus horarios y su lista de lo que deja pasar. Que dos sistemas tengan API no significa que se entiendan. Significa que la conversación es posible. El trabajo, el precio y los problemas están en la conversación, no en las puertas.

Lo que la API expone y lo que no

Este es el punto donde se rompen la mitad de los proyectos. Una API no da acceso a todo lo que hay dentro del sistema. Da acceso a lo que el fabricante decidió abrir, en el formato que decidió, con las limitaciones que decidió.

Ejemplos concretos que verás:

• Un ERP español de los clásicos te deja leer el stock, pero no te deja leerlo por almacén. Si tienes tienda online y tres puntos de venta, ese detalle te cambia el proyecto entero.
• La API te da el precio de tarifa, pero no las tarifas por cliente. Y tú vendes a mayoristas con condiciones distintas.
• Puedes crear un pedido, pero no puedes modificarlo. Para cambiar una línea hay que anular y volver a crear, y eso descuadra la numeración contable.
• El campo «descripción larga» está limitado a 255 caracteres porque el software es de 2011 y nadie lo ha tocado.

Un proveedor serio te dice esto en la semana uno, después de mirar la documentación. Uno que no ha mirado nada te lo dice en el mes tres, con el presupuesto ya consumido.

Las cinco cosas que encarecen una integración

Cuando dos presupuestos para «conectar el ERP con la tienda» difieren en 6.000 €, casi siempre es por alguna de estas.

1. El límite de llamadas

Casi todas las APIs limitan cuántas peticiones puedes hacer por segundo (el rate limit). Shopify, por ejemplo, ronda las 2 peticiones por segundo en planes estándar; otras plataformas van por minuto o por hora. Parece un detalle técnico. No lo es.

Si tienes 3.000 referencias y quieres sincronizar el stock, a 2 peticiones por segundo tardas unos 25 minutos en dar una vuelta completa. Con 30.000 referencias, más de cuatro horas. Ahí el proyecto deja de ser «un script que actualiza stock» y pasa a ser un sistema que decide qué actualizar y cuándo. Eso cuesta más y es la razón real de que tu stock nunca cuadre.

2. Cómo se entera cada sistema de que algo ha cambiado

Hay dos formas. La primera es preguntar cada X minutos: «¿ha cambiado algo?». Se llama polling y es sencillo, lento y gasta llamadas. La segunda es que el sistema te avise cuando pasa algo, con un webhook: un mensaje que el sistema envía solo a una dirección que tú le das.

Los webhooks son mejores casi siempre. Pero no todos los sistemas los tienen, y los que los tienen a veces los pierden. Pregunta cuál se va a usar y qué pasa si un webhook no llega.

3. Autenticación

Cómo demuestra el programa que tiene permiso para entrar. Hay APIs con una clave fija y ya está. Hay otras con tokens que caducan cada hora y hay que renovar, o con procesos de autorización que exigen que alguien entre a mano en un panel cada 90 días. Si tu integración se cae cada trimestre porque a nadie se le ocurrió renovar un token, es porque esto no se habló.

4. Si hay entorno de pruebas

Un sandbox es una copia del sistema donde probar sin tocar datos reales. Si el ERP no lo tiene, tu proveedor va a probar contra producción. Con tus pedidos y tus clientes. Eso obliga a trabajar de noche, a ir mucho más despacio y a asumir riesgo. Sube el precio y debe subirlo.

5. Versiones y caducidad

Las APIs cambian. Shopify saca versión nueva cada trimestre y retira las viejas al año. Amazon, Meta y Google hacen algo parecido. Eso significa que una integración no es una obra terminada, es una instalación que hay que mantener. Si en el presupuesto no aparece esa palabra, la vas a pagar aparte.

Una integración no se entrega, se mantiene. Quien te la vende como obra cerrada te está vendiendo la mitad.

Las preguntas que tienes que hacer

No necesitas entender las respuestas al detalle. Necesitas ver si el otro las tiene preparadas o improvisa. Estas ocho valen para cualquier proyecto.

1. ¿Has leído la documentación de las dos APIs? Si la respuesta es «lo miramos al empezar», el presupuesto es una estimación a ojo.
2. ¿Qué datos concretos vais a mover, en qué dirección y cada cuánto? Que te lo digan en una tabla. «Stock: del ERP a la web, cada 10 minutos, solo referencias con movimiento». Así de concreto.
3. ¿Qué pasa si la API del otro lado está caída media hora? La respuesta buena incluye reintentos y una cola de pendientes. La mala es «no debería pasar».
4. ¿Quién se entera de que ha fallado y cómo? Si nadie recibe una alerta, te enteras tú por un cliente cabreado tres días después.
5. ¿Hay entorno de pruebas en los dos sistemas? Y si no lo hay, cómo pensáis probar.
6. ¿Dónde vive el código de la conexión? ¿En un servidor tuyo, en uno suyo, dentro de la tienda? Si vive en su infraestructura, pregunta qué pasa el día que dejéis de trabajar juntos.
7. ¿Qué pasa cuando el fabricante saque una versión nueva? Quién lo vigila y quién lo paga.
8. ¿Qué se queda fuera de este presupuesto? La pregunta más rentable de todas. Un buen proveedor tiene lista.

La API no siempre es la mejor opción

Esto es lo que casi nadie te va a decir, porque una integración por API se factura mejor que un fichero.

Para bastantes negocios, un CSV que se genera cada noche y se sube por FTP resuelve el 90 % del problema por una fracción del coste. Si tu rotación es baja, si nadie compra a las tres de la mañana, si tienes stock de sobra en casi todo el catálogo, la sincronización en tiempo real es un lujo técnico que no te devuelve nada.

La pregunta correcta no es «¿tiene API?». Es «¿cuánto me cuesta que este dato llegue tarde?». Si vendes cerámica artesanal y tienes tres unidades de cada pieza, te cuesta mucho. Si vendes material de oficina con reposición semanal, casi nada.

El día que falla, que fallará

Toda integración se cae. El proveedor de transporte cambia un campo, el hosting del ERP se reinicia, alguien renueva un certificado. Lo que distingue un proyecto bien hecho de uno mal hecho no es que no falle, es qué pasa cuando falla.

Tres cosas que deberían estar en cualquier integración que pagues:

• Reintentos con espera. Si la llamada falla, se vuelve a intentar a los 30 segundos, luego a los 2 minutos, luego a los 10. No en bucle infinito cada segundo, que es como te bloquean la cuenta.
• Idempotencia. Palabra fea, idea simple: que enviar dos veces el mismo pedido no cree dos pedidos. Pregunta por ella. Si el proveedor pone cara rara, mal.
• Registro y aviso. Un sitio donde ver qué pasó y a qué hora, y un correo o un mensaje cuando algo lleva un rato roto. Sin esto estás ciego.

Y una cosa más: qué se hace con lo que no pasó. Si la web estuvo desconectada del ERP dos horas, ¿los pedidos de esas dos horas entran solos cuando vuelve, o hay que meterlos a mano? La respuesta cambia mucho un lunes de rebajas.

Cómo leer la línea del presupuesto

«Integración con ERP vía API — 4.500 €» no es un presupuesto. Es un titular. Lo que deberías poder leer, aunque sea en media página:

• Qué flujos, en qué dirección y con qué frecuencia.
• Qué campos concretos de cada flujo. Sobre todo los conflictivos: almacenes, tarifas, packs, variantes, impuestos.
• Qué queda explícitamente fuera.
• Cómo se prueba y qué se considera «terminado». Un criterio verificable, tipo «50 pedidos reales seguidos sin intervención manual».
• Qué pasa después: mantenimiento, quién vigila, tiempo de respuesta si se cae.
• De quién es el código y las credenciales.

Ese último punto lo pasa por alto casi todo el mundo y luego duele. Las claves de acceso a tu ERP, a tu tienda y a tus agencias son tuyas. Que estén guardadas en el portátil del desarrollador que se fue de la empresa es un problema que descubres en el peor momento posible.

Un caso típico

Cadena de seis tiendas de calzado, unos 2.500 modelos entre tallas y colores, TPV propio en cada punto de venta y una web que factura alrededor de 40.000 € al mes. Quieren stock único. Todos los sistemas «tienen API».

Lo que aparece al mirar de verdad: el TPV solo expone ventas del día anterior, no en tiempo real. La web puede recibir stock por API sin problema. El ERP tiene API pero no distingue reservas de stock disponible. Y nadie ha decidido qué pasa cuando la última unidad de un 42 negro se vende a la vez en Valencia y en la web.

El problema no era técnico. Era que unificar el stock de tienda física y online exige decidir reglas de negocio antes de escribir una línea de código: cuánto stock se reserva para tienda, cuál es la fuente de verdad, quién gana cuando hay conflicto. Esas decisiones las tomas tú, no el programador. Y si no las tomas, las toma él por defecto, mal, y te enteras en diciembre.

Cuando un proveedor te dice «lo conectamos por API» y tú le preguntas «¿qué pasa si se vende la misma unidad en dos sitios a la vez?», la respuesta te dice más del proyecto que cualquier presupuesto.