Integración por API: qué es y qué pedir a tu proveedor
Una integración por API conecta dos programas para que se pasen datos sin copiarlos a mano. Lo que la hace fiable no es la API, sino cómo trata los fallos: avisos repetidos o desordenados, reintentos sin duplicar, una fuente de verdad por dato y alertas cuando algo falla.
Una integración por API conecta dos programas para que se pasen datos sin que nadie los copie a mano: la tienda online avisa al programa de gestión de que hay un pedido, o tu sistema consulta a la pasarela si un cobro se ha completado. Lo que separa una buena integración de una mala no es la API, sino qué pasa cuando algo falla.
Qué es una API, sin tecnicismos
Una API es la puerta de servicio de un programa: define qué se le puede pedir, cómo hay que identificarse y qué responde. Si el programa de facturación tiene una API, otro programa puede crear un cliente o consultar una factura sin que una persona abra la pantalla.
Muchas de las API que usarás funcionan sobre HTTP, el mismo protocolo que la web. Cuando están bien documentadas, pueden describirse con la especificación OpenAPI, un formato estándar que permite a personas y a programas entender qué ofrece un servicio sin leer su código fuente. Si un proveedor te dice que «tiene API» pero no puede enseñarte esa documentación, ya sabes por dónde empezar a preguntar.
Cuatro formas de conectar dos programas
| Forma | Cómo funciona | Cuándo encaja | Riesgo principal |
|---|---|---|---|
| API | Un programa pide o envía datos al otro cuando lo necesita | Casi siempre que el otro programa la ofrezca | Cambios de versión y límites de uso |
| Webhook | El otro programa te avisa cuando pasa algo (un pago, un pedido) | Cuando importa enterarse en el momento | Avisos repetidos o desordenados |
| Intercambio de ficheros | Uno exporta un fichero y el otro lo importa, a una hora fija | Programas antiguos o volúmenes grandes que no corren prisa | Datos con horas de retraso y errores que nadie mira |
| Automatizar la pantalla | Un robot hace clic donde lo haría una persona | Último recurso, cuando no hay otra puerta | Se rompe cuando cambia la pantalla |
En la práctica, una integración seria suele combinar las dos primeras: webhooks para enterarse de lo que pasa y llamadas a la API para completar o comprobar los datos.
API o webhook: la diferencia que importa
Con una API, tu programa pregunta. Con un webhook, el otro programa te avisa. El webhook es más rápido y ahorra consultas, pero trae tres sorpresas que conviene conocer antes de programar nada. La documentación de Stripe, una pasarela de pago, las describe con claridad:
- El mismo aviso puede llegar dos veces. Stripe advierte que los puntos de conexión de webhooks pueden recibir el mismo evento más de una vez, y recomienda registrar los identificadores de los eventos ya procesados.
- Los avisos pueden llegar desordenados. Stripe no garantiza la entrega de eventos en el orden en que se han generado.
- Si tu sistema no responde, se reintenta. En modo activo, Stripe intenta entregar los eventos durante un máximo de tres días con un retroceso exponencial.
Cambia el nombre del proveedor y el problema es el mismo. Una integración que da por hecho que cada aviso llega una sola vez y en orden puede acabar cobrando dos veces, duplicando un pedido o marcando como pagada una factura que no lo está.
Qué exigir para que no falle en silencio
Da igual si la integración la hace tu proveedor de software, un informático externo o tu propio equipo. Estas preguntas separan una integración que aguanta de una que funciona en la demostración:
- Documentación y entorno de pruebas. ¿Hay documentación de la API y un entorno donde probar sin tocar datos reales?
- Permisos mínimos. La clave de acceso solo debe poder hacer lo que la integración necesita, y debe poder cambiarse sin parar el negocio.
- Repetir sin duplicar. En HTTP, un método es idempotente si repetir la misma petición tiene el mismo efecto que hacerla una vez. Cuando la operación no lo es, como crear un cobro, algunas API ofrecen claves de idempotencia para poder reintentar sin crear el objeto dos veces.
- Reintentos con espera. Si el otro programa no responde, se vuelve a intentar más tarde, no mil veces seguidas.
- Una fuente de verdad por dato. Si el precio se cambia en la tienda y en el ERP, ¿cuál manda? Decídelo antes, no después del primer conflicto.
- Historial y alertas. Cada envío queda registrado, y si algo falla alguien se entera ese mismo día, no a final de mes.
- Versiones. ¿Qué pasa cuando el otro programa cambia su API? Pregunta cómo se avisa y cuánto tiempo conviven la versión vieja y la nueva.
Si tu programa no tiene API
Pasa a menudo con programas de gestión antiguos o con aplicaciones hechas en casa. Las opciones, de mejor a peor: una exportación programada que el otro sistema importe; leer directamente su base de datos, con mucho cuidado y solo para leer; o automatizar la pantalla. Si nada de eso es razonable, quizá la pregunta no sea cómo integrarlo, sino si ha llegado el momento de sustituirlo. Lo tratamos en qué hacer con el software legacy.
Integraciones que hemos construido
En los sistemas que desarrollamos hay integraciones con pagos, correo transaccional, portales inmobiliarios y el callejero oficial. En nuestro marketplace inmobiliario, el contacto de quien pregunta por un anuncio entra directamente en el CRM de la agencia que lo publica, y en la restauración, los pedidos online entran en el TPV. El motor de reglas que usamos para automatizar avisos funciona con historial de cada ejecución, reintentos y sin duplicados.
Dos casos concretos que explicamos a fondo: integrar una pasarela de pago y sincronizar el stock entre la tienda física y la online. Y si lo que buscas es un sistema que ya nazca conectado, empieza por nuestro desarrollo de software a medida.
Fuentes consultadas
Comprobadas el 26 de septiembre de 2026. Enlazamos la fuente original para que puedas consultar el texto vigente.
- OpenAPI Specification (versión vigente). OpenAPI Initiative.
- Recibir eventos de Stripe en tu punto de conexión de webhook. Stripe (documentación oficial).
- RFC 9110, HTTP Semantics: métodos idempotentes. IETF (RFC Editor).
- API Reference: Idempotent requests. Stripe (documentación oficial).
Preguntas frecuentes
¿Qué es una API en palabras sencillas?
Es la puerta de servicio de un programa: define qué se le puede pedir, cómo identificarse y qué responde. Gracias a ella, otro programa puede crear un cliente, consultar un pedido o registrar un cobro sin que una persona lo teclee.
¿Qué diferencia hay entre una API y un webhook?
Con una API tu programa pregunta cuando lo necesita; con un webhook el otro programa te avisa cuando pasa algo. A menudo conviene combinarlos: el aviso llega por webhook y los datos se completan o comprueban con la API.
¿Cuánto cuesta integrar dos programas por API?
Depende de la calidad de la documentación, de si hay entorno de pruebas, de cuántos datos y en qué sentido viajan y de cómo se gestionan los errores. Una integración que solo funciona cuando todo va bien es barata al principio y cara después.
¿Puedo conectar mi programa si no tiene API?
A veces sí: con exportaciones programadas, leyendo su base de datos con cuidado o automatizando la pantalla como último recurso. Si ninguna opción es razonable, suele compensar valorar su sustitución.
¿Algo de esto encaja con tu negocio? Cuéntanos cómo lo haces hoy.