Property API
Publicá tus propiedades en varios portales inmobiliarios con un solo modelo. Mapaprop ya implementó las APIs de cada portal, así que en vez de integrar una por una nos mandás el objeto una vez y nosotros lo traducimos.
📋 Antes de salir a producción, mirá Cambios de la API — y después, cada tanto. Es la lista de lo que cambió con su fecha: un campo que se fue, uno nuevo, un comportamiento distinto. Es corta a propósito: sólo entra lo que te obliga a hacer algo.
property-v1 no cambia de versión, así que ésa es la única forma de saber si algo se movió desde
que escribiste tu integración.
Antes de todo: tus credenciales
Para llamar a cualquier endpoint de esta sección necesitás un access token, y para eso tu aplicación tiene que estar registrada.
Primeros pasos con OAuth2 — registrás tu aplicación, te damos tus credenciales y con ellas obtenés el token
Tres cosas de ahí que conviene tener claras antes de seguir:
| El token vence | a los 14 días. Un 403 inesperado suele ser eso, no un problema de permisos |
| No mandás un identificador de tu app | va adentro del token y lo resolvemos nosotros. No hay nada que configurar ni ningún id que guardar |
| Lo de tu app y lo de cada cliente son dos niveles | hoy lo único que se configura a nivel de tu app son los webhooks. Todo el resto —la ficha del cliente, sus cuentas de portal, sus propiedades— va por cliente, con el header x-client-ref |
Hay dos formas de llegar acá, y el token se obtiene distinto en cada una.
Si sos un integrador —tu app publica el inventario de otras inmobiliarias— registrás tu
aplicación y obtenés el token con client_id/client_secret, como dice arriba.
Si sos cliente de Mapaprop y querés automatizar tu propia cuenta, no registrás nada: contratás Property API y activás tu Token de API con un clic desde Configuración > API Token. Es el mismo token para todos tus servicios de API, y no vence. Cómo se hace: Property API Token.
Buenas prácticas — los flujos completos
Esta página lista la API por recurso: qué hace cada endpoint. Si lo que necesitás es el orden —qué va antes de qué, qué decidís en cada paso y qué cuesta— ésa es la otra mitad de la documentación, y conviene empezar por ahí.
Buenas prácticas — las cuatro reglas que valen para todos los flujos: qué se hace una vez y qué cada vez, qué es gratis y qué gasta cupo, qué guardar de tu lado y qué pasa si reintentás
Dar de alta un cliente — una sola vez por cliente, y la única bifurcación real: enlace o credencial, según el portal
Publicar un aviso — el caso base, de punta a punta
Publicar un desarrollo — las unidades van antes del desarrollo; acá el orden es el contenido
Recibir consultas — el único flujo donde no empujás, recibís
Dar de baja — bajar un aviso, desconectar una cuenta y borrar un cliente son tres cosas distintas
Cuando algo no sale — por dónde empezar a mirar, de gratis a caro
1. Empezá por acá
En este orden: primero entendés el modelo, después armás el objeto y lo probás, y recién ahí declarás a tu cliente y conectás sus cuentas de portal. Sin una cuenta conectada no se puede publicar.
El modelo de propiedad — por qué las claves son las mismas en todos los países
El objeto JSON de la propiedad — los campos, sus reglas y cuáles son obligatorios
POST /properties/verify — verificá tu objeto antes de publicar. No crea ni publica nada
Clientes — declarala una vez; sus propiedades heredan el nombre, el teléfono y el email
Conectar sus cuentas de portal — Argenprop, Cabaprop y MercadoLibre: guardás el token que ya tenés
Conectar con un enlace — Zonaprop: tu cliente autoriza desde un enlace que le mandás
Consultar y desconectar — el estado de las conexiones de tu cliente, y desvincular
POST /properties — el alta: guarda la propiedad, te devuelve el paId y guarda tus imágenes en nuestros servidores
1B. Desarrollos inmobiliarios
Un edificio en pozo, un barrio cerrado, una torre en construcción. Se mandan con el mismo endpoint que una propiedad —no hay un modelo nuevo que aprender— y te devolvemos los números calculados de sus unidades: disponibilidad, comercialización separando venta de alquiler, m², rango de precios por moneda y distribución por tipología.
El objeto JSON del desarrollo — el grupo development, sus campos y cómo se declaran las unidades
Verificar y dar de alta un desarrollo — el flujo, el orden que funciona y qué validamos de más
developmentStats — los números calculados de sus unidades, campo por campo
2. Catálogo
Los datos de referencia que necesitás para mapear tu sistema contra el nuestro. Se bajan una vez y se guardan: no son endpoints para llamar en cada alta.
Zonas — cómo mapear las tuyas contra las nuestras, y qué formato tiene el código
GET /property-catalog-v1/zones — la lista completa de un país, paginada
La cascada: zones1 / zones2 / zones3 — las mismas zonas, de a un nivel
GET /property-attributes — tipos, operaciones, estados y amenities
3. Publicar
Publicar en un portal — publicá una propiedad ya cargada en el portal de tu cliente
Despublicar de un portal — dar de baja el aviso. Es idempotente
Consultar el estado en el portal — la URL del aviso, si sigue online y las visitas. ⚠️ gasta una llamada de la cuota del cliente
La clave publication — la configuración por portal
GET /properties/{paId} — consultar una propiedad
GET /properties — listar todas las de un cliente, con el estado de cada portal
PUT /properties/{paId} — modificar: reemplazo total, con diff de lo que cambió
DELETE /properties/{paId} — borrar. No da de baja tus avisos en los portales
4. Leads
Leads — qué es un lead, el objeto que devolvemos, el cupo compartido y por qué no los guardamos
Las consultas de toda la cuenta — una llamada trae las de todos los avisos. Es el camino normal
Las consultas de una propiedad — las de un aviso puntual
Qué modo soporta cada portal — si en ese portal las consultas se piden o llegan solas. Leelo en vez de darlo por sabido