Verificar y dar de alta un desarrollo

No hay endpoints nuevos. Un desarrollo se verifica con POST /property-v1/properties/verify y se da de alta con POST /property-v1/properties, igual que una propiedad. Lo que cambia es lo que validamos y lo que te devolvemos.

POST /property-v1/properties/verify     ← probá sin guardar nada
POST /property-v1/properties            ← el alta
PUT  /property-v1/properties/{paId}     ← modificar (y cargar o cambiar las unidades)

1. Empezá por el verify. Siempre.

verify no crea nada, no publica nada y no gasta cuota de ningún portal. Le mandás el objeto y te devuelve exactamente lo que pasaría: qué datos nos llegaron bien, qué le falta a cada portal, en qué zona publicaríamos y cómo quedaría el aviso.

Con un desarrollo eso vale más que con una propiedad suelta, porque hay más cosas que pueden no cerrar: las unidades tienen que existir y estar libres, y la clase de emprendimiento se deduce de los campos que mandás.

curl -X POST https://property-api.mapaprop.com/property-v1/properties/verify \
  -H "Authorization: Bearer {tu-token}" \
  -H "x-client-ref: {tu-cliente}" \
  -H "Content-Type: application/json" \
  -d '{ "canonical": { … tu desarrollo … } }'

El verify te muestra lo mismo que el POST mandaría. No es una versión reducida ni una aproximación: es el mismo motor, con la escritura apagada.

2. El orden que funciona

1. Las unidades primero. POST /properties de cada una, y te guardás su paId.
2. El desarrollo después, con los códigos de sus unidades en development.units.

Si lo hacés al revés, las unidades no existen todavía y te las reportamos como not_found — el desarrollo se guarda igual, pero no va a poder publicarse hasta que la lista resuelva.

También podés hacerlo en dos tiempos

Un desarrollo se puede dar de alta sin unidades y cargarlas después con PUT. Es el flujo normal cuando el proyecto sale a la venta antes de tener la tipología cerrada.

⚠️ El PUT reemplaza la lista entera, no agrega: si el desarrollo tiene 10 unidades y el PUT manda 3, queda con 3. Mandá siempre la lista completa.

Y eso convive con el tope de 100 de la tabla de abajo, porque lo que se cuenta son las unidades que entran y salen, no las que el desarrollo ya tiene. El detalle, con ejemplos, está en el tope: 100 unidades que CAMBIAN.

3. Qué validamos de más

Sobre todo lo que ya validamos de una propiedad, un desarrollo suma:

El tipo. El grupo development exige type: 23. Con otro tipo te devolvemos un error de contrato en vez de elegir por nuestra cuenta: adivinar cuál de los dos quisiste decir es cómo se ensucia una base.

Los seis campos del grupo, que son obligatorios: totalBuildingArea, totalLandArea, totalGarages, minAmbiences, minRooms, minBathrooms. Si falta uno te lo nombramos por su ruta en tu JSON (development.minRooms), no por nuestro nombre interno.

Las unidades, una por una: que existan, que estén vivas, que sean de tu mismo cliente, que no estén ya en otro desarrollo y que no armen un ciclo. Las siete reglas están en el objeto del desarrollo.

La clase de emprendimiento. Si declarás campos de las dos (casas y pisos de edificio) te devolvemos el conflicto nombrando los campos de cada lado. No elegimos por vos.

4. Un objeto con problemas se guarda igual

Esto sorprende, así que vale decirlo claro: si una unidad no resuelve, el POST te devuelve 201 y el desarrollo queda guardado, con los problemas listados.

No es laxitud: el objeto es tuyo. Guardarlo te permite corregir la unidad y reintentar sin volver a mandar todo, y los problemas son el diagnóstico de por qué todavía no se puede publicar — no un rechazo.

Lo que sí es bloqueante es publicar: un desarrollo no se publica con unidades de menos.

Las dos excepciones, que sí son error

5. Qué te devolvemos

La respuesta tiene la misma forma que la de una propiedad, más un bloque developmentStats con los números calculados de sus unidades: cuántas hay, cuántas disponibles, el rango de precios por moneda, la distribución por tipología.

Eso está en developmentStats, y es la parte que más conviene leer: son datos que no tenés que calcular vos.

6. Y después

developmentStats — los números calculados, campo por campo

El objeto JSON del desarrollo — los campos y las reglas de las unidades

Publicar en un portal — con el objeto ya verificado