Clientes
Antes de dar de alta tu primera propiedad, declarás la ficha del cliente dueño: su nombre, su contacto y su sucursal. Se hace una vez por cliente y desde ahí todas sus propiedades la heredan.
Decimos cliente y no "inmobiliaria" a propósito: puede ser una inmobiliaria, una desarrolladora,
un administrador de alquileres o un particular. La API lo llama customer, y su id es tu clientRef.
Los cuatro métodos
| Qué hace | ||
|---|---|---|
POST | Declara el cliente y te devuelve el customerId que le asignamos | property-api-create |
GET | Devuelve lo que declaraste | property-api-read |
PUT | Cambia los datos. No cambia el customerId | property-api-update |
DELETE | Da de baja el cliente. Reversible | property-api-delete |
Los cuatro van a la misma ruta, /property-v1/customers, y el cliente sobre el que operás lo dice el
header x-client-ref — igual que en el resto de la API.
De estos datos salen el nombre, el teléfono, el email y la dirección que se publican en cada aviso.
Por qué no va en cada propiedad
Lo pidió un integrador, y tenía razón: tenías que repetir los mismos datos del cliente en cada alta, y eran los mismos para sus 500 propiedades.
Declarándolos una vez, las propiedades nuevas los heredan solas y no tenés que mandarlos nunca más.
customerId — lo emitimos nosotros
El customerId (MAPAPROP-PA-000002) no lo elegís vos: lo asignamos al crear la ficha, y es el
código con el que ese cliente se identifica ante los portales.
El customerId no cambia nunca. No lo cambia el PUT, y una ficha dada de baja y reactivada
vuelve con el mismo. Si cambiara, los avisos que tu cliente ya tiene publicados quedarían colgados de
un código que dejó de existir.
Tu clientRef es otra cosa: es tu identificador, el que usás para decirnos de qué cliente hablás.
Nosotros no lo interpretamos.
El ciclo de vida
POST → el cliente queda declarado, con su customerId
├── GET consultar
├── PUT cambiar los datos (el id no se toca)
└── DELETE dar de baja ──┐
│
POST (otra vez) ←─────────────────────┘ lo reactiva, con el MISMO customerId
Un POST repetido sobre un cliente que ya existe no duplica nada ni emite otro id: devuelve el que
está, con created: false.
Qué pasa si no la declarás
| Endpoint | Sin ficha |
|---|---|
POST /properties | 400 con rule: account_required |
POST /properties/verify | 200 — es un probador: simula los datos del cliente con un placeholder y lo declara en customerSource: "placeholder" |
Por eso podés probar tu objeto el primer día, antes de declarar nada.
Qué podés hacer con la ficha declarada
La ficha no es sólo el contacto que heredan las propiedades: es el cliente al que después le conectás portales y le publicás.
| Para | Andá a |
|---|---|
| Conectar su cuenta de Zonaprop | Conectar con un enlace |
| Conectar Argenprop, Cabaprop o MercadoLibre | Conexiones a portales |
| Ver el estado de sus conexiones, o desconectar | Conexiones a portales |
| Entender el cupo mensual de Zonaprop | Cupo mensual y límites |
| Cargar sus propiedades | Alta de propiedades |
El código que le asignamos acá (MAPAPROP-PA-000123) es con el que tu cliente se identifica ante
los portales. Por eso la ficha va primero: sin ella no se puede emitir un enlace de conexión.
Todavía no hay forma de listar tus clientes por API. Cada método opera sobre un clientRef a la
vez, así que el registro de qué clientes declaraste lo llevás vos. Si te hace falta enumerarlos
—sobre todo para saber cuáles están activos y cuáles dados de baja— escribinos a dev@mapaprop.com y
lo priorizamos.