developmentStats — the development's calculated numbers

When the object is a development, the response carries a developmentStats block with the aggregated indicators of its units: how many there are and in what state, how much was commercialized separating sale from rent, the available square metres, the price per currency and the distribution by unit type.

These are the same numbers we show in our own development panel. You do not have to walk through the units or calculate anything: it comes resolved, in verify, in the POST, in the PUT and in the GET.

1. Do not confuse it with canonical.development

They are two different blocks, and the difference is whose each one is:

That is why it is not inside canonical: only your object goes there, verbatim.

2. The complete block

{
  "units": {
    "total": 4,
    "available": 1,
    "sold": 1,
    "rented": 1,
    "reserved": 1,
    "suspended": 0,
    "withOperation": 3,
    "availabilityRate": 25
  },
  "sale":  { "units": 3, "commercialized": 2, "rate": 67 },
  "rent":  { "units": 1, "commercialized": 1, "rate": 100 },
  "otherOperation": { "units": 0 },
  "buildingArea": {
    "unit": "m2",
    "total": 220,
    "available": 62,
    "unavailable": 158,
    "sold": 48,
    "rented": 48,
    "reserved": 62
  },
  "prices": {
    "mixedCurrencies": true,
    "byCurrency": {
      "USD": { "units": 3, "from": 85000, "to": 120000, "total": 325000 },
      "ARS": { "units": 1, "from": 450000, "to": 450000, "total": 450000 }
    }
  },
  "typology": {
    "byAmbiences":    { "2": 2, "3": 2 },
    "byRooms":        { "1": 2, "2": 2 },
    "byBuildingArea": { "48": 2, "62": 2 },
    "byLandArea":     { "70": 4 }
  }
}

The names are the same ones you post: your covered square metres are buildingArea, your bedrooms are rooms, your total square metres are landArea. There is no new vocabulary to learn.

3. units — how many and in what state

withOperation counts units, not states: a unit that is sold and reserved counts as one. That is why available + withOperation always equals total, and the available count never goes negative.

4. 🔴 sale and rent — sale and rent are measured SEPARATELY

This is the part most worth understanding, because it is where a single average lies.

Sale and rent are different businesses and are not averaged together. Each one is measured against its own universe, and the event that counts as commercialized is different:

In the example above, rent is placed at 100 % and sale at 67 %. A single average would say "75 %" and would say nothing about either business.

rate: null is not 0

A rent-only development returns "sale": { "units": 0, "commercialized": 0, "rate": null } — not a 0 % of sales that do not exist.

otherOperation

Units under barter, transfer, co-ownership or auction do not enter either rate: they are neither sale nor rent. They are counted separately so that sale.units + rent.units + otherOperation.units always equals the total and no unit disappears.

5. buildingArea — the covered square metres

unavailable is an or, not a sum: the square metres of a unit that is sold and reserved are discounted once. That is why sold + rented + reserved can add up to more than unavailable, and available never goes negative.

6. 🔴 prices — always per currency

A development can have units in different currencies, and that is normal. So the price is always returned broken down:

We do not return a total that crosses currencies. A range mixing dollars with pesos is not degraded data: it is false data. If you want a single total, convert it yourself with whatever exchange rate you use — that is your decision, not ours.

⚠️ A unit with a price but no declared currency does not enter the breakdown: we do not invent one for it.

7. typology — the distribution of the units

How many units there are of each configuration. They are maps: the key is the value and the value is how many units.

"byAmbiences": { "2": 18, "3": 22 } reads as: 18 units with 2 rooms and 22 with 3.

They have no ceiling: if you have units with 9 rooms, the "9" key appears. And a configuration that no unit has does not appear — it does not come back as 0.

Remember our model's naming crossover, the same as in a standalone property: ambiences is the total number of rooms and rooms is the bedrooms.

8. A development with no units

The block comes back the same, with the counters at zero, the maps empty and both rates as null. It is not the same as absent: it is telling you the development exists and has no units loaded yet, which is a normal state.

The block does not appear when the object is not a development.

9. And next

The development JSON object — how it is declared, and the unit rules

Verify and create a development — the flow and what we validate

GET /properties — look up a development already loaded