Mapaprop

Publishing a development

A development is a building or a neighbourhood with units inside. If you have already read publishing a listing, the flow is the same with one difference that changes the whole order.

The units are created BEFORE the development that groups them. This is not a style recommendation: the development references them, so if they do not exist yet there is nothing to reference. It is the number one mistake in this flow and it cannot be fixed going forwards — you have to go back.

The path

1 · each unit, separately         POST /properties             ← FIRST. They are normal properties
2 · the development grouping them POST /properties             ← references the ones from step 1
3 · check it                      POST /properties/verify      free
4 · publish                       PUT  …/publication/{portal}  ← ONE call: parent + units
5 · status and takedown           same as a listing

1 · The units first

Each unit is a normal property: it is created with the same POST /properties as any other.

⚠️ A unit is not a development. It has its own property type —apartment, house, plot— and it only inherits the development's if you get it wrong while building it. If that happens, the publish attempt flags it unit by unit, naming the type the portal does not recognise.

Store each one's code or identifier: it is what the development will reference them by.

2 · The development

Another POST /properties, with the development object and the list of the units from step 1.

Two things worth knowing beforehand:

  • A unit belongs to a single development. If it is already part of another, we tell you naming which one — we do not reassign it on our own initiative.
  • A development can be stored with no units and have them loaded later. What cannot be done is publishing it empty.

3 · Check it (free, and here it pays more than ever)

The checker reviews the development and each unit. Since publishing it is a single call to the portal, a problem in one single unit can hold up everything — and checking costs nothing.

The checker works on the object you send it, not on what we already have stored. To check a development that already exists, send it with its current units: since they already belong to that same development, it will flag them for you. It is a known limitation and it is not a mistake on your part.

4 · Publishing: one call, the parent and the units

PUT …/publication/{portal} with the development. The units travel inside it: you do not publish them one by one.

That has two consequences worth being clear about:

The allowanceit is one call, not one per unit. A development with 40 units costs the same as one with 2
The plandevelopments consume a plan of their own, different from a standalone listing's. Which one it is and how many your client has is what you see with the plans lookup

Depending on how many units it has, the portal may answer in one of two ways: confirming each listing, or confirming only the development and processing the units afterwards. What we return is explained in the development's response; the mode is not yours to choose.

5 · Status, updating and takedown

Same as a listing: publishing again updates, the takedown is idempotent, and the status can be read for free on our side or by paying one call to the portal.

⚠️ The development and its units have separate statuses. Ask about the development's through the development: asking about a unit as if it were a standalone listing will not tell you what you are after.

The three order mistakes, and how they look

If you…We tell you like this
send the development before the unitswe cannot find those units, with the code that does not exist
reference a unit that already belongs to another developmentwe name the development that has it
let the units inherit the development's typethe attempt flags each unit with the type the portal will not accept

All three come out before reaching the portal if you checked. If you did not check, they come out after spending the call.

Which portals support it

Publishing developments is not available on every portal, and on those where it is, your client needs to have the corresponding product contracted — which is different from the standalone listing one. The table is in Publication; if the portal does not support it, the attempt tells you without spending allowance.