Cómo funciona una web inmobiliaria conectada a CMS y CRM

La conexión empieza por la fuente de datos

Una web conectada obtiene información del sistema que administra el inventario y puede enviar consultas a una herramienta de seguimiento. La conexión puede ser unidireccional o bidireccional, según lo que permita cada proveedor. No se debe asumir que todos los cambios se reflejan al instante o que cualquier CRM admite las mismas operaciones.

IrigoyenDev desarrolla plataformas e integraciones según alcance. Trabajas directamente con Andrés Irigoyen para revisar la operación, los sistemas existentes y la viabilidad técnica. No ofrecemos un software inmobiliario empaquetado ni declaramos compatibilidad con proveedores sin comprobar sus requisitos.

Qué hace la web, qué hace el CMS y qué hace el CRM

• Web pública: presenta catálogo, búsqueda, fichas y vías de consulta.
• CMS o gestor de inventario: permite editar propiedades, imágenes y estados de publicación según permisos.
• CRM: organiza contactos, responsables, actividades y oportunidades comerciales.
• Integración: transporta y transforma los datos acordados entre sistemas, con control de errores.

Un CMS no se convierte en CRM por tener formularios. Un CRM tampoco reemplaza necesariamente la administración de imágenes o contenidos. Las funciones pueden convivir en una aplicación, pero deben definirse antes de construirla.

Un flujo de publicación y consulta

El siguiente flujo es ilustrativo, no una integración que afirmemos tener instalada para todos los clientes. Ayuda a establecer qué se debe probar en un proyecto concreto.

1. El equipo crea o modifica una propiedad en el sistema elegido como fuente del inventario.
2. La integración valida campos y relaciona el identificador de la propiedad con su ficha pública.
3. La web actualiza los datos autorizados después de recibir o consultar el cambio.
4. Un visitante solicita información desde la ficha y el backend valida la consulta.
5. El sistema registra el contacto o la oportunidad según las reglas de duplicados y asigna un responsable.
6. El equipo verifica recepción y seguimiento; una notificación fallida activa el procedimiento acordado.

APIs, webhooks e importaciones: alternativas posibles

Una API permite intercambiar datos mediante operaciones definidas por el proveedor. Antes de integrarla revisamos documentación, acceso, campos, límites, costos y entorno de pruebas. Tener una API no implica que permita publicar propiedades o crear contactos con todos los datos que necesitas.

Si el sistema ofrece webhooks, puede enviar una notificación cuando ocurre un evento. Otra alternativa es consultar cambios periódicamente. GitHub documenta esta diferencia entre notificaciones por eventos y consultas a una API; sirve para explicar el patrón, no para acreditar funciones de un proveedor inmobiliario.

• Fuente: GitHub, explicación de webhooks y consultas periódicas — Referencia conceptual consultada el 9 de octubre de 2026.

Cuando no existe una API adecuada, se puede evaluar una importación autorizada de archivos con un formato estable. Su frecuencia y controles serán distintos. La actualización visible puede depender de caché, procesos de imágenes o disponibilidad del proveedor: se acuerda una expectativa y se mide en pruebas.

Propiedades, consultas y portales no son el mismo flujo

Publicar una ficha, enviar una consulta a un CRM y exportar inventario a un portal son integraciones diferentes. Cada canal requiere revisar permisos y contrato. No prometemos sincronización con todos los portales ni reutilizamos credenciales o mecanismos de exportación sin autorización.

• Propiedades: identificador estable, precio y unidad, superficies, imágenes y estado.
• Consultas: referencia de propiedad, datos mínimos de contacto y responsable de atención.
• Portales: formato y campos aceptados, operaciones disponibles y condiciones de publicación.
• Conflictos: qué sistema manda si alguien modifica el mismo dato en dos lugares.

Qué ocurre cuando una sincronización falla

La integración necesita un plan para eventos repetidos, datos incompletos y fallos externos. Un registro recibido dos veces no debería generar dos propiedades ni dos oportunidades idénticas. La deduplicación debe distinguir un reintento técnico de una nueva necesidad del mismo contacto.

• Validar y rechazar cambios incompletos sin sobrescribir información correcta.
• Registrar estado y hora de la última actualización comprobada.
• Definir reintentos, alertas y revisión manual según el sistema.
• Reconciliar el inventario cuando faltan eventos o hay diferencias.
• Establecer qué se muestra mientras un cambio de disponibilidad no pudo confirmarse.

Accesos y datos privados separados del catálogo

Las credenciales de integración deben permanecer en el servidor y los permisos deben limitarse a las operaciones necesarias. Solo se publican campos aprobados para la ficha: datos de propietarios, notas internas y documentos privados no deben pasar al catálogo público.

OWASP recomienda HTTPS y control de acceso en los endpoints de APIs no públicas. Estos controles son parte del diseño técnico; no equivalen a una certificación ni a una declaración automática de cumplimiento legal. Evita enviar datos personales o mensajes a eventos de analytics.

• Fuente: OWASP, seguridad de APIs REST — HTTPS y control de acceso; consulta del 9 de octubre de 2026.

Un proyecto real y su alcance documentado

Calafate Propiedades reúne catálogo público, panel administrativo, correos de consultas y tratamiento de imágenes. El caso muestra una aplicación que conecta presentación y administración. No lo presentamos como prueba de una integración con un CRM externo ni de publicación automática en todos los portales.

• Revisar el caso Calafate Propiedades

Pruebas antes de publicar la integración

1. Crear una propiedad de prueba y comprobar campos e imágenes en la ficha.
2. Cambiar precio y disponibilidad; verificar la actualización según el plazo acordado.
3. Enviar una consulta de prueba autorizada y comprobar registro, asignación y recepción.
4. Repetir una entrega técnica y verificar que no duplica el registro.
5. Simular datos inválidos y fallos de proveedor; comprobar recuperación y alertas.
6. Revisar accesos, campos privados y funcionamiento móvil antes de abrir al público.

La entrega debe incluir responsables, documentación y continuidad. Care puede cubrir mantenimiento acordado; nuevas APIs, migraciones o cambios que exceden el plan se estiman por separado. La ampliación de SEO/GEO y contenidos se prioriza con la operación funcionando.

Preguntas frecuentes

Enlaces relacionados

• Guía de diseño web, SEO y GEO inmobiliario
• Ventajas y medición de una web inmobiliaria profesional
• Plataformas para inmobiliarias
• CMS, CRM y plataformas a medida
• Mantenimiento Care
• Contacto con Andrés Irigoyen

Solicitar diagnóstico