DEVELOPING

El modelo de propiedad

Enviás el JSON según nuestro modelo y nosotros lo traducimos al formato de cada portal.

Mapaprop es multipaís, y para que eso funcione hay una sola cosa que tenés que entender bien: el vocabulario es único. El tipo casa es el mismo valor en todos los países. Lo que cambia de un país a otro es cómo se llama en pantalla —"Departamento", "Piso", "Apartamento"— y qué opciones están disponibles, no el valor que mandás.

Si integrás varios países, aprendés un vocabulario, no uno por país.

Tipo y operación

En el JSON de la propiedad viajan como números:

CampoQué es
typeEl tipo de propiedad
propertyOperationLa operación

Esos números son estables: significan lo mismo en todos los países.

Las operaciones son siete:

propertyOperationOperación
1Venta
2Alquiler
3Alquiler temporario
4Permuta
5Traspaso
6Compartir
7Remate

Los tipos son veintitrés y no los listamos acá, porque no todos están habilitados en todos los países. Los obtenés del catálogo.

El catálogo: de dónde salen los valores

GET /property-attributes te devuelve, para un país, todo lo que ese país acepta. Cada entrada trae:

CampoQué es
pa_keyLa clave en texto — apartment, house, pool
pa_key_legacyEl valor estable que mandás en el JSON
pa_labelLa etiqueta traducida, para mostrarle a tu usuario
pa_typeLa naturaleza del dato: bool, list o string
pa_group_subtypeLa familia, para agrupar en pantalla — ammenities, spaces, services

Con eso podés traducir en las dos direcciones: de tu sistema al nuestro, y de nuestra respuesta a algo legible para tu usuario.

Pedí el catálogo del país de la propiedad, no de uno solo. Un tipo puede estar habilitado en Argentina y no en Perú.

Y tenelo presente: no validamos los valores contra el catálogo. La validación de la alta verifica que los campos obligatorios estén y sean del tipo correcto — nada más. Un valor que ese país no usa no se rechaza: se guarda, y la propiedad queda publicada con un dato equivocado. El catálogo no es una sugerencia: es la única forma de saber qué mandar.

Los atributos

Además de los campos fijos, la propiedad lleva un arreglo attributes con todo lo demás: los amenities, las terminaciones, las orientaciones. Ahí es donde vive la riqueza de la ficha, y es el mismo lugar para los tres tipos de dato:

pa_typeQué esQué mandás
boolLo tiene o no lo tiene — pileta, parrilla, cochera cubiertala entrada del atributo, marcada como presente
listUna opción entre varias — tipo de aire acondicionado, orientaciónla entrada de la opción elegida, con su valor
stringUn valor con texto propiola entrada, con la clave del valor

Los nombres exactos de los campos de cada entrada, copialos del ejemplo de El objeto JSON de la propiedad — no son los mismos para las tres naturalezas, y no coinciden con los del catálogo. Ese ejemplo es el contrato.

Qué mandás vos y qué ponemos nosotros

El catálogo trae más campos de los que tenés que mandar. La regla es simple: mandá sólo lo que vos sabés y nosotros no.

Quién lo pone
El identificador del clienteNosotros, desde tu token — si lo mandás en el body, se ignora
Todo el restoVos

El arreglo attributes se guarda tal como lo mandás, etiquetas e idioma incluidos: no lo reescribimos contra el catálogo. Eso significa que si inventás una etiqueta, es esa la que se va a mostrar.

Por eso: armá cada entrada a partir del catálogo del país en vez de escribirla a mano. Pedí GET /property-attributes para el país de la propiedad y copiá la entrada tal como viene.

Un ejemplo del vocabulario único

La misma propiedad, publicada en dos países, manda el mismo valor:

// Argentina
{ "type": 1, "propertyOperation": 1, "currency": "USD" }

// España — mismo tipo, mismo número
{ "type": 1, "propertyOperation": 1, "currency": "EUR" }

Lo que cambia es lo que tu usuario ve: en Argentina el catálogo devuelve pa_label: "Departamento"; en España, pa_label: "Piso".

Si GET /property-attributes no devuelve el país que buscás, ese país todavía no está habilitado para publicar. No conviertas los valores a mano ni asumas los de otro país: escribinos y lo habilitamos.

Ver también