Un cliente se registra, hace un pedido o se apunta al boletín. La información ya está en tu tienda, pero tu equipo también puede necesitarla en su CRM o en su herramienta de marketing. Hemos desarrollado un sistema general de webhooks para ShopinCloud que permite preparar esos avisos, elegir su destino y consultar qué ha ocurrido con cada envío desde el panel de administración.

De la exportación manual a los avisos por evento

Exportar un archivo de clientes puede resolver una carga inicial. Mantener después otra aplicación al día exige repetir el trabajo e identificar qué registros son nuevos, qué pedidos han cambiado y quién ha modificado su preferencia sobre el boletín.

Además, cada situación tiene un significado distinto. Abrir una cuenta no equivale a comprar. Crear un pedido no demuestra que se haya pagado. Y registrarse en una tienda tampoco implica suscribirse a sus comunicaciones comerciales.

Un webhook es un aviso que una aplicación envía a otra cuando ocurre algo. En este desarrollo, ShopinCloud prepara la notificación asociada a ese momento y la pone en cola para enviarla a la dirección configurada. Así, una integración puede reaccionar al evento sin esperar a una nueva exportación manual.

Los seis eventos que hemos incorporado

  • Cliente registrado: comunica un nuevo registro completado en la web.
  • Pedido creado: informa de la creación del pedido, con sus datos, líneas e importe.
  • Pedido pagado: comunica que ha alcanzado el estado configurado en la tienda como confirmación de pago.
  • Cambio de estado del pedido: informa de una transición efectiva e incluye el estado anterior y el nuevo.
  • Alta en el boletín: comunica una nueva suscripción registrada.
  • Baja del boletín: informa del cambio de preferencia registrado.

El evento de pedido pagado sigue la configuración de estados de ShopinCloud, incluido un cambio manual a ese estado. No representa una conciliación bancaria ni un seguimiento de cobros parciales. Esta distinción ayuda a definir qué debe interpretar la herramienta que recibe los datos.

Qué podrías hacer con estas notificaciones

Imagina, como ejemplo hipotético , una tienda que quiere organizar el seguimiento de sus nuevos clientes. Una integración podría recibir el aviso de registro y utilizarlo para crear o actualizar la ficha correspondiente en su CRM.

En otro caso, el equipo podría separar los pedidos recibidos de los confirmados como pagados. Con dos eventos distintos, la aplicación receptora dispondría de información para preparar acciones diferentes: revisar un pedido pendiente o incorporar una venta confirmada a su seguimiento comercial.

Para el boletín, una alta o una baja podrían trasladarse a la herramienta de marketing correspondiente. El desarrollo mantiene separadas la creación de una cuenta y la suscripción: un registro sin la preferencia de newsletter marcada no se interpreta como un alta en el boletín.

Estas posibilidades requieren una aplicación receptora preparada para interpretar el mensaje y realizar la acción deseada. El sistema general de webhooks no es un conector nativo de Clientify ni de otro CRM concreto. Según el destino, hará falta una integración directa o un intermediario que adapte los datos a su API.

Configuración desde el panel habitual de ShopinCloud

La administración utiliza los listados, formularios, pestañas y ventanas habituales del panel. Desde Sistema → Webhooks se puede identificar cada integración con un nombre, indicar su dirección HTTPS y seleccionar los eventos que debe comunicar.

También se puede elegir una tienda concreta o un destino general del proyecto, según el ámbito de gestión del usuario. Una misma configuración admite varios eventos, y se pueden mantener destinos distintos para necesidades diferentes.

Formulario real de ShopinCloud con la URL de destino y los seis eventos disponibles para configurar un webhook
Captura del entorno local: configuración de ejemplo con datos ficticios, sin guardar ni activar esta conexión.

El formulario incluye opciones de autenticación y una prueba con datos ficticios. Además, cada webhook puede pausarse. Esta pausa detiene la adquisición de sus envíos pendientes; una petición que ya haya comenzado puede terminar.

Historial, intentos y reenvíos

Configurar una dirección es solo una parte del trabajo. También hace falta distinguir entre una notificación pendiente, una aceptada por el receptor y otra que ha encontrado un error. Para ello hemos incorporado un historial con filtros por evento, estado y fecha.

Desde cada entrega se puede abrir su detalle, consultar los datos preparados y revisar los intentos registrados. Una respuesta correcta del receptor confirma la aceptación de la petición, pero no demuestra por sí sola que el CRM haya completado todas sus acciones posteriores.

Historial real de webhooks en ShopinCloud con fecha, evento, estado, intentos y respuesta HTTP
Historial del entorno de prueba. Las notificaciones mostradas están pendientes y tienen cero intentos: la imagen no acredita su recepción en una aplicación externa.

El sistema contempla reintentos automáticos ante fallos temporales, con esperas progresivas y un límite de intentos. También permite solicitar el reenvío manual de una entrega terminada mientras conserve sus datos.

Los avisos se procesan en segundo plano para que la compra o el registro no esperen la respuesta de la aplicación externa. Conservan los datos y el destino del momento en que se registraron. Cada evento mantiene un identificador estable que el receptor debe utilizar para reconocer posibles repeticiones y evitar duplicar acciones.

Compatibilidad con los webhooks anteriores

El nuevo sistema convive con las direcciones que ya podían configurarse en los estados de pedido. Esas integraciones conservan su funcionamiento y su formato anteriores; no se transforman automáticamente en nuevas suscripciones.

Las nuevas notificaciones incorporan firma y opciones de autenticación. Los datos se seleccionan expresamente para cada evento, sin incluir contraseñas ni notas internas del pedido. Las credenciales de autenticación tampoco se muestran en el historial de entregas.

Qué hemos comprobado y qué necesita cada integración

El desarrollo está implementado y hemos revisado su administración en el entorno local: configuración, guardado, filtros, historial, detalle y formularios de prueba. La cola, los reintentos y el aislamiento entre tiendas también cuentan con pruebas automatizadas.

La puesta en marcha en cada instalación requiere preparar el módulo, disponer de un receptor compatible y comprobar que las tareas programadas estén operativas. Después hay que verificar el recorrido completo, desde el evento hasta la acción esperada en la aplicación de destino. Las comprobaciones locales no acreditan todavía una entrega real en un CRM concreto ni una activación general en todas las tiendas.

Si quieres conocer el conjunto de herramientas del ecommerce, puedes consultar las funcionalidades de ShopinCloud . Y si necesitas conectar registros, pedidos o preferencias del boletín con otra aplicación, cuéntanos qué información quieres trasladar y a qué herramienta para estudiar el flujo de integración.