Verify and create a development

There are no new endpoints. A development is verified with POST /property-v1/properties/verify and created with POST /property-v1/properties, just like a property. What changes is what we validate and what we return.

POST /property-v1/properties/verify     ← try it out without saving anything
POST /property-v1/properties            ← the creation
PUT  /property-v1/properties/{paId}     ← edit (and load or change the units)

1. Start with verify. Always.

verify creates nothing, publishes nothing and uses up no portal quota. You send the object and it returns exactly what would happen: which data reached us correctly, what each portal is missing, which zone we would publish in, and how the listing would look.

With a development that matters more than with a standalone property, because there are more things that can fail to add up: the units have to exist and be free, and the kind of development is inferred from the fields you send.

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

verify shows you the same thing the POST would send. It is not a reduced version or an approximation: it is the same engine, with writing turned off.

2. The order that works

1. The units first. POST /properties for each one, and keep its paId.
2. The development afterwards, with its unit codes in development.units.

If you do it the other way around, the units do not exist yet and we report them as not_found — the development is still saved, but it will not be publishable until the list resolves.

You can also do it in two stages

A development can be created without units and have them loaded later with PUT. That is the normal flow when the project goes on sale before the unit mix is settled.

⚠️ PUT replaces the entire list, it does not append: if the development has 10 units and the PUT sends 3, it ends up with 3. Always send the complete list.

And that coexists with the limit of 100 in the table below, because what is counted are the units that come in and go out, not the ones the development already has. The details, with examples, are in the limit: 100 units that CHANGE.

3. What we validate on top

On top of everything we already validate for a property, a development adds:

The type. The development group requires type: 23. With any other type we return a contract error instead of choosing on our own: guessing which of the two you meant is how a database gets dirty.

The six group fields, which are required: totalBuildingArea, totalLandArea, totalGarages, minAmbiences, minRooms, minBathrooms. If one is missing we name it by its path in your JSON (development.minRooms), not by our internal name.

The units, one by one: that they exist, that they are live, that they belong to the same client of yours, that they are not already in another development and that they do not form a cycle. The seven rules are in the development object.

The kind of development. If you declare fields from both (houses and building floors) we return the conflict naming the fields on each side. We do not choose for you.

4. An object with problems is saved anyway

This is surprising, so it is worth saying plainly: if a unit does not resolve, the POST returns 201 and the development is saved, with the problems listed.

This is not laxity: the object is yours. Saving it lets you fix the unit and retry without sending everything again, and the problems are the diagnosis of why it cannot be published yet — not a rejection.

What is blocking is publishing: a development is not published with units missing.

The two exceptions, which are errors

5. What we return

The response has the same shape as a property's, plus a developmentStats block with the calculated numbers of its units: how many there are, how many are available, the price range per currency, the distribution by unit type.

That is in developmentStats, and it is the part most worth reading: it is data you do not have to calculate yourself.

6. And next

developmentStats — the calculated numbers, field by field

The development JSON object — the fields and the unit rules

Publish to a portal — with the object already verified