APIs e integraciones: conectar tu web con el CRM, las reservas y los pagos

Hace un tiempo trabajamos con un restaurante de Marbella que recibía las reservas a través de un formulario de su web. Cada mañana, alguien del equipo abría el correo, copiaba nombre, fecha, hora y número de comensales en el programa de reservas y respondía a cada cliente para confirmar. Media hora diaria, todos los días, con el riesgo lógico de equivocarse en un número. Cuando conectamos la web directamente con su sistema de reservas, esa media hora desapareció y el cliente pasó a ver la disponibilidad real y a recibir su confirmación al instante.

Eso es, en esencia, una integración: hacer que la web hable directamente con las herramientas que ya usa tu negocio. El CRM donde gestionas los contactos, la agenda donde están las citas, la pasarela que cobra los pedidos, el programa de facturación. Cuando esas conversaciones están bien diseñadas, la web deja de ser un escaparate que genera tareas y pasa a ser una pieza que las resuelve.

En esta guía explico qué hay detrás de esas conexiones, qué opciones existen y qué detalles marcan la diferencia entre una integración que funciona el día del estreno y una que sigue funcionando dentro de tres años.

01Qué es una API, sin jerga

Una API (Application Programming Interface, interfaz de programación de aplicaciones) es la puerta que un programa abre para que otros programas le pidan cosas de forma ordenada. Igual que una ventanilla con un formulario normalizado: si rellenas los campos que piden, en el formato que piden, obtienes una respuesta predecible.

En la web, la mayoría de las API siguen un estilo llamado REST: cada recurso tiene una dirección (endpoint), como /contacts o /bookings, y se usan los verbos de HTTP para actuar sobre él (GET para leer, POST para crear, PATCH para modificar, DELETE para borrar). Los datos viajan en JSON, un formato de texto legible tanto para máquinas como para personas.

Tres conceptos más completan el vocabulario básico:

• →Autenticación. Para usar una API necesitas demostrar quién eres, con una clave secreta (API key) o con OAuth, el sistema que te muestra la pantalla de «Esta aplicación quiere acceder a tu cuenta» y te permite conceder permisos concretos.
• →Webhooks. Avisos que el otro servicio envía a tu web cuando ocurre algo: un pago completado, una reserva cancelada, un contacto actualizado. Evitan tener que preguntar cada minuto si hay novedades.
• →Límites de uso (rate limits). Casi todas las API limitan cuántas peticiones puedes hacer por segundo o por día. Una integración bien hecha los respeta y se adapta.

Así se ve, por ejemplo, el envío de un contacto desde el formulario de la web a un CRM:

{
  "email": "laura@ejemplo.com",
  "firstname": "Laura",
  "phone": "+34600000000",
  "lead_source": "web-formulario-contacto",
  "utm_campaign": "reformas-primavera",
  "consent_privacy": true,
  "consent_marketing": false,
  "message": "Quiero presupuesto para reformar una cocina"
}

02Cuatro formas de integrar y cuándo encaja cada una

No todas las conexiones necesitan programación a medida. Elegir el nivel adecuado es la primera decisión, y la que más influye en coste y mantenimiento.

Los widgets merecen un comentario. Son la vía rápida, pero traen el diseño del proveedor, que a menudo encaja mal con la marca, y suelen cargar bastante JavaScript, lo que se nota en el rendimiento. En nuestros proyectos los usamos cuando el proveedor permite personalizarlos de verdad y los cargamos solo cuando el visitante los necesita. Cuando la reserva o la compra es el centro del negocio, solemos apostar por la integración directa, que permite diseñar la experiencia completa con la identidad de la marca. En UX de reservas y citas hablamos de cómo diseñar ese flujo para que se complete sin esfuerzo.

03CRM: que cada contacto llegue completo y con contexto

Conectar los formularios con el CRM (HubSpot, Pipedrive, Salesforce, Zoho, Holded y similares) es probablemente la integración con mejor relación entre esfuerzo y beneficio. Lo que marca la diferencia es el contexto que viaja con cada contacto:

• →Origen: qué formulario, en qué página y en qué idioma.
• →Campaña: los parámetros UTM de la visita, guardados en campos ocultos del formulario, para saber qué anuncio o publicación trajo a esa persona.
• →Consentimientos: si aceptó la política de privacidad y, por separado, si quiere recibir comunicaciones comerciales, con fecha y texto aceptado.
• →Deduplicación: buscar el contacto por correo antes de crearlo, para actualizar la ficha en lugar de duplicarla.

La propia validación y protección del formulario antes de enviar nada al CRM (comprobaciones en servidor, antispam, mensajes de error) la tratamos en formularios por dentro.

04Reservas y citas: la disponibilidad real, en tu web

Cada sector tiene sus herramientas de referencia: sistemas de reservas de mesa como CoverManager o TheFork Manager en restauración, motores de reservas y channel managers en hoteles, plataformas de citas como Doctoralia en salud o agendas como Calendly y Cal.com para servicios profesionales. La mayoría ofrecen una API o, al menos, un widget.

Lo que buscamos en una integración de reservas:

1. 01Disponibilidad en tiempo real consultada a la API, nunca copiada a mano en la web.
2. 02Una única fuente de verdad. La agenda vive en el sistema de reservas; la web solo la consulta y le envía solicitudes. Así no hay dos calendarios que se desincronizan.
3. 03Confirmación inmediata en pantalla y por correo, con la opción de añadir la cita al calendario del cliente.
4. 04Cancelaciones y cambios sincronizados por webhook, para liberar el hueco al instante.
5. 05Bloqueo temporal del hueco mientras el cliente termina de rellenar los datos, si el sistema lo permite, para evitar dobles reservas.

05Pagos: cobrar con seguridad sin tocar una tarjeta

En España las opciones habituales son las pasarelas internacionales (Stripe, PayPal, Adyen) y el TPV virtual de tu banco, normalmente sobre la plataforma Redsys, que además permite cobrar con Bizum. Cualquiera de ellas se puede integrar de forma excelente si se respetan unos principios.

Que los datos de la tarjeta nunca pasen por tu servidor

La norma PCI DSS regula cómo se protegen los datos de tarjetas. La forma más sencilla de cumplirla es usar la página de pago alojada por la pasarela o sus campos de pago incrustados, que envían la tarjeta directamente a la pasarela. Tu web recibe solo una confirmación y un identificador. Así, la carga de cumplimiento se reduce al cuestionario más sencillo de la norma (SAQ A) y el riesgo para tu negocio es mínimo.

La autenticación reforzada, integrada en el flujo

Desde la directiva europea PSD2, los pagos online requieren en general autenticación reforzada del cliente, que en tarjetas se resuelve con 3-D Secure 2: el banco puede pedir una confirmación en su app. Las pasarelas modernas lo gestionan solas; lo que nos toca en diseño es que ese paso se vea como parte natural del pago y que el cliente vuelva a una página de confirmación clara.

El webhook manda

Este es el detalle técnico más importante de cualquier integración de pagos. Cuando el cliente paga, la pasarela lo redirige a tu página de «gracias», pero esa redirección puede fallar: el cliente cierra la pestaña, pierde la cobertura o el banco tarda. La confirmación fiable es el webhook que la pasarela envía a tu servidor. Es ese aviso, y no la visita a la página de gracias, el que debe marcar el pedido como pagado, enviar el correo y avisar al almacén.

06Integrar bien por dentro: los detalles que dan fiabilidad

Esta es la parte invisible que separa una integración de demostración de una que aguanta años de uso real. La lista que seguimos en el estudio:

• →Claves secretas en el servidor. Las API keys se guardan en variables de entorno y se usan desde el servidor, nunca en el código que se descarga el navegador, donde cualquiera podría leerlas.
• →Permisos mínimos. Cada clave, con acceso solo a lo que necesita: crear contactos, no borrarlos.
• →Webhooks verificados. Cada aviso entrante se comprueba con la firma que envía el proveedor, para asegurar que viene de quien dice.
• →Idempotencia. Si el mismo aviso llega dos veces, cosa que pasa, el pedido no se procesa dos veces. Muchas API admiten una clave de idempotencia para eso.
• →Reintentos y colas. Si el CRM no responde, la solicitud se guarda y se reintenta más tarde con esperas crecientes. El cliente no tiene por qué notarlo.
• →Registro y alertas. Cada llamada fallida queda registrada y, si se repiten los errores, alguien recibe un aviso.
• →Versiones fijadas. Usa una versión concreta de la API y planifica las actualizaciones cuando el proveedor anuncie cambios.
• →Entorno de pruebas. Toda integración se prueba en sandbox con datos ficticios antes de tocar datos reales.

Si la web está construida con una arquitectura desacoplada, estas piezas encajan de forma muy natural; lo explicamos en qué es un CMS headless.

Clave: una integración fiable no es la que nunca falla, es la que sabe qué hacer cuando algo falla: reintentar, avisar y no perder ningún dato por el camino.

Protección de datos en las integraciones

Cada servicio al que envías datos personales actúa como encargado del tratamiento según el RGPD, y necesitas un contrato de encargo (artículo 28) que los grandes proveedores incluyen en sus condiciones. Además:

• →Envía solo los datos necesarios para cada servicio.
• →Comprueba dónde se alojan. Si están fuera del Espacio Económico Europeo, verifica que hay una garantía adecuada, como la adhesión del proveedor al Marco de Privacidad de Datos UE-EE. UU. o cláusulas contractuales tipo.
• →Recoge en tu política de privacidad qué servicios reciben qué datos.
• →Respeta los consentimientos en todo el recorrido: si alguien no aceptó comunicaciones comerciales, el CRM debe saberlo.

07Cómo planificar una integración paso a paso

1. 01Dibuja el flujo. Qué pasa, en qué orden y qué datos se mueven: «el cliente reserva, se crea la cita, se envía la confirmación, se añade al CRM». Una hoja con flechas basta.
2. 02Elige la fuente de verdad de cada dato: dónde vive la agenda, dónde vive el cliente, dónde vive el pedido.
3. 03Revisa la documentación de cada proveedor: endpoints, webhooks, límites, entorno de pruebas, coste por uso.
4. 04Decide el nivel de integración con la tabla de arriba.
5. 05Diseña los estados de la interfaz: cargando, confirmado, sin disponibilidad, error de pago. Cada uno con su mensaje claro.
6. 06Desarrolla y prueba en sandbox, incluidos los casos raros: pago rechazado, webhook duplicado, servicio caído.
7. 07Publica con vigilancia: registros activos y una prueba real completa el primer día.
8. 08Documenta qué está conectado con qué, dónde están las claves y quién recibe las alertas.

Conectar una web con el resto del negocio es de los trabajos que más satisfacción dan, porque el efecto se nota desde el primer día en el tiempo de las personas. En SIMA lo abordamos dentro del desarrollo web y de aplicaciones: diseñamos el flujo, elegimos el nivel de integración adecuado y lo construimos para que sea fiable y fácil de mantener. Si estás pensando en conectar tu web con tu CRM, tu agenda o tus cobros, escríbenos y lo dibujamos juntos.