Guía
Qué es una API y para qué le sirve a tu empresa
Una API es la puerta que un programa abre para que otros programas le pidan o le envíen datos sin que nadie los copie a mano. Te explicamos qué es una API sin tecnicismos, con ejemplos de empresa, en qué se diferencia de un webhook, qué preguntar a tu proveedor de software y qué hacer si tu programa no tiene.
Qué es una API, en pocas palabras
Una API es la forma ordenada que tiene un programa de dejar que otros programas le pidan datos o le den órdenes. En vez de que una persona abra el programa, busque un cliente y copie su dirección en otro sitio, el segundo programa hace la petición directamente («dame los datos del cliente 1532») y recibe la respuesta en un formato que entiende. Si dos programas tienen API, se pueden conectar para que la información pase sola de uno a otro.
Para una empresa, eso significa menos datos tecleados dos veces, menos errores de copia y procesos que avanzan sin esperar a que alguien tenga un hueco. La API no es un programa que se compre aparte: es una parte del programa que ya usas, o que le falta. Y de si la tiene, y de cómo es, depende casi todo lo que podrás automatizar con él.
La analogía de la ventanilla
Piensa en la ventanilla de un organismo público. No entras al archivo a buscar tu expediente: rellenas un impreso con los campos que te piden, lo entregas y te devuelven una respuesta con un formato fijo. Una API funciona igual:
- El archivo es la base de datos del programa: nadie de fuera entra.
- El impreso es el formato de la petición: qué datos hay que mandar y cómo.
- Cada ventanilla atiende un trámite: una consulta clientes, otra crea facturas. En la jerga, cada una es un endpoint.
- La acreditación que enseñas es la clave de API: dice quién pide y qué puede pedir.
- El manual de trámites es la documentación: sin ella, nadie sabe qué ventanillas hay ni qué impreso rellenar.
Si tu proveedor te dice que tiene «una API REST que devuelve JSON», traducido significa que las peticiones viajan por internet, como quien visita una dirección web, y que las respuestas llegan en un formato de texto estándar que cualquier programa sabe leer. Es lo más habitual hoy.
Para qué sirve una API: ejemplos en una empresa
Usas APIs a diario sin verlas. Estos ejemplos son ilustrativos, para ver cómo encajan las piezas.
El pago con tarjeta en una tienda online
Cuando un cliente paga en tu tienda, la tienda no procesa la tarjeta: se la pasa por API a la pasarela de pago, que habla con el banco y devuelve «aceptado» o «rechazado». Lo que ocurre después, como una devolución o un cargo disputado, la pasarela se lo comunica a tu tienda por su cuenta. Stripe, por ejemplo, lo explica en su documentación de webhooks.
La facturación que se conecta con el banco
Imagina una asesoría que quiere saber qué facturas se han cobrado sin repasar el extracto a mano. Su programa de facturación lee los movimientos del banco y los casa con las facturas pendientes. Esto tiene marco legal: el Real Decreto-ley 19/2018, que traspone la directiva europea de servicios de pago, regula los «servicios de información sobre cuentas»: empresas registradas que, con tu consentimiento explícito, acceden solo a las cuentas que tú designes.
El formulario de la web que llega al CRM
Alguien pide información en tu web. En lugar de un correo que se pierde en una bandeja, el formulario envía los datos por API al CRM, que crea el contacto, lo asigna al comercial de su zona y le avisa. Si el contacto ya existía, se actualiza en vez de duplicarse.
Otros usos habituales: generar la etiqueta de envío en la web de la empresa de transporte sin teclear direcciones, sincronizar el stock entre la tienda online y el almacén, o que tu programa de gestión envíe avisos por WhatsApp Business cuando cambia el estado de un pedido.
API y webhook: preguntar o que te avisen
Con una API, tu programa pregunta: «¿hay pedidos nuevos?». Con un webhook, el otro programa te avisa en cuanto pasa algo: «acaba de entrar un pedido, aquí lo tienes». Es la diferencia entre llamar cada rato al restaurante para saber si tu pedido está listo o que te manden un mensaje cuando lo está.
| API (consulta) | Webhook (aviso) | |
|---|---|---|
| Quién inicia | Tu programa, cuando lo necesita | El otro programa, cuando ocurre algo |
| Rapidez | Depende de cada cuánto preguntes | Casi inmediata |
| Para qué | Consultar, crear o modificar datos | Enterarte de eventos: pago recibido, mensaje nuevo, pedido creado |
| Qué necesita | Una clave y la documentación | Una dirección en internet siempre disponible que reciba los avisos |
En la práctica se combinan: el webhook avisa de que ha entrado un pago y tu sistema usa la API para marcar la factura como cobrada. Con los webhooks hay dos cuidados: comprobar que el aviso viene de quien dice (los buenos proveedores firman cada aviso, como hace Stripe) y estar preparado para recibir el mismo aviso dos veces sin duplicar nada. Si un programa no ofrece webhooks, la alternativa es preguntarle por API cada pocos minutos: funciona, pero gasta más peticiones y nunca es inmediato.
Cómo se integran dos programas por API
Que dos programas tengan API no significa que se conecten solos. Alguien tiene que decidir y construir cinco cosas:
- El disparador: qué hace que los datos se muevan (un pedido nuevo, un cambio de estado, cada noche a las dos).
- La correspondencia de campos: qué campo de un programa va a cuál del otro, y qué pasa si uno tiene datos que el otro no.
- La identificación: cómo se sabe que el «Bar Pepe» del CRM es el mismo cliente que «PEPE HOSTELERÍA, S.L.» en facturación.
- Los errores: qué ocurre si un programa no responde, si falta un dato o si algo no cuadra.
- El registro: constancia de qué pasó, cuándo y desde dónde, para poder revisarlo.
Para conexiones sencillas entre programas conocidos, herramientas como n8n, Make o Zapier traen conectores ya hechos sobre las API de cada programa; te ayudamos a elegir en n8n, Make o Zapier. Cuando hay mucha lógica, volumen o programas sin conector, compensa un desarrollo a medida. Es lo que hacemos en integración de sistemas y APIs, siempre con permisos mínimos, registro y avisos cuando algo falla.
Qué preguntar a tu proveedor de software sobre su API
«Sí, tenemos API» no dice casi nada. Antes de contratar un programa, o de planear una integración con el que ya tienes, pregunta esto:
| Pregunta | Por qué importa |
|---|---|
| ¿Está documentada públicamente? | Sin documentación clara, cada integración es un trabajo de adivinación. Pide el enlace. |
| ¿Qué permite: leer, crear, modificar, borrar? | Muchas API solo dejan consultar, o no dan acceso a los datos que necesitas, como las líneas de cada pedido. |
| ¿Cómo se autentica? | Lo deseable es crear claves distintas por integración, con permisos limitados, y poder revocarlas cuando quieras. |
| ¿Qué límites tiene? | Casi todas limitan las peticiones por minuto o por día. Con mucho volumen, un límite bajo obliga a rediseñar. |
| ¿Cuesta dinero? | Puede venir incluida, exigir un plan superior, ser un módulo aparte o cobrarse por uso. Pregúntalo antes de firmar. |
| ¿Tiene webhooks? | Te ahorra preguntar cada pocos minutos y permite reaccionar al momento. |
| ¿Hay entorno de pruebas? | Probar con tus datos reales es arriesgado; un entorno de pruebas lo evita. |
| ¿Cómo avisan de los cambios? | Si cambian la API sin aviso, tu integración se rompe. Busca versiones y plazos de aviso. |
Y una más, que no es técnica: si un proveedor se niega a darte acceso por API a tus propios datos, tómalo como una pista de lo difícil que será irte algún día.
Mi programa no tiene API: qué alternativas hay
Es muy habitual, sobre todo en programas de gestión veteranos o instalados en un servidor de la oficina. No está todo perdido. Estas son las alternativas, de más a menos recomendable:
- Pregunta bien. A veces la API existe pero es de pago, está en una versión más moderna del programa o la gestiona el distribuidor.
- Exportaciones e importaciones de ficheros. Si el programa exporta a Excel o CSV y permite importar, ese intercambio se puede programar. No es inmediato, pero es fiable y el fabricante lo soporta.
- La base de datos. Leer de ella suele ser viable con cuidado, aunque su estructura puede cambiar con cada actualización y el fabricante puede negarte soporte si algo falla. Escribir directamente es otra cosa: te saltas las comprobaciones del programa y, en facturación, puedes crear facturas sin el registro que exige Verifactu. Solo lo planteamos en casos muy acotados.
- El correo. Si el programa envía informes por email o los pedidos llegan por correo, se pueden leer y procesar solos. Es la vía que contamos en automatizar facturas y albaranes.
- En último caso, automatizar la pantalla. Un robot (lo que se llama RPA) imita a una persona: abre el programa, hace clic y teclea. Sirve cuando no hay otra vía, pero se rompe cuando cambia una pantalla, es lento, necesita un usuario con su contraseña y hay que vigilarlo siempre.
Seguridad básica al conectar programas por API
Una clave de API es como una llave maestra: quien la tiene puede hacer todo lo que esa clave permita, sin contraseña ni doble factor. Lo básico:
- Trata las claves como contraseñas. Nunca por correo, en un Excel compartido ni escritas en el código; guárdalas en un gestor de secretos.
- Una clave por integración. Si algo falla o dejas de trabajar con un proveedor, revocas solo esa sin romper lo demás.
- Permisos mínimos. Si la integración solo lee facturas, su clave no debe poder borrarlas. Stripe, por ejemplo, recomienda sus claves restringidas para la mayoría de usos.
- Renueva y revoca las claves cada cierto tiempo y siempre que se vaya alguien con acceso.
- Solo conexiones cifradas (HTTPS) y registro de quién accede a qué.
- Solo los datos necesarios. Con datos personales, cuanto menos viaje, menos riesgo y menos obligaciones.
Si encargas una API propia, para que tus clientes o proveedores se conecten a tu sistema, pide que se revise contra el OWASP API Security Top 10, la lista de referencia de fallos de seguridad en APIs. El primero es de sentido común: que cambiando un número en la petición alguien pueda ver la factura de otro cliente. Comprobar que cada usuario solo accede a lo suyo es obligatorio, no un extra.
Siguientes pasos: cómo plantear tu primera integración
- Elige un trasvase de datos concreto que hoy se haga a mano: los pedidos de la web al programa de gestión, los contactos del formulario al CRM.
- Apunta los programas implicados y averigua, con las preguntas de arriba, si tienen API y qué permite.
- Cuenta cuánto se repite y cuánto tiempo lleva: es lo que dirá si compensa.
- Decide qué pasa cuando algo no cuadra y quién lo revisa.
- Empieza por una sola integración, mídela unas semanas y amplía después.
Así trabajamos nosotros: antes de presupuestar, revisamos qué vías ofrece cada programa (API, ficheros, base de datos o correo) y te decimos qué es viable y con qué fiabilidad. Si una integración no es posible o no compensa, te lo decimos. Si tienes dos programas que no se hablan y alguien hace de puente copiando datos, escríbenos con sus nombres y te contamos qué opciones hay.