DEVELOPING

The states that travel with the property

There are two different things the object can declare, and it is worth not mixing them up:

Axis	What it says	Fields
The OPERATION's state	the operation closed: it was reserved, sold, rented	`reserved` · `sold` · `rented`
The PUBLICATION's state	the listing does not show, even though the operation is still open	`suspended`

Both travel inside the object and are applied when you publish. There is no separate method.

{ "code": "CMT-0014", "type": 1, "operation": 1, "sold": true }

The scope of this page is those two axes. If a third one appears in the future, it will get its own section here — it does not get mixed in with these.

The OPERATION's state

Field	What it says
`reserved`	The operation is reserved
`sold`	It closed as a sale
`rented`	It closed as a rental

🔴 They do not say the property is occupied: they say the operation closed. That is the distinction that governs the two rules below.

Rule 1 · One or none, never two

A property has ONE state or none — counting suspended too. If you send two of them on, the object is rejected in the verifier and on creation, before anything is published.

{ "field": "operationStatus",
  "rule": "exclusive",
  "value": ["reserved", "sold"],
  "detail": "una propiedad tiene UN estado o ninguno: vinieron 2 prendidos (reserved, sold). Dejá sólo el que corresponde y apagá el resto — si la propiedad se reservó y después se vendió, el estado es `sold` y `reserved` va en false." }

The most common case: it was reserved, then sold, and the source system left reserved on. The correct state is sold, and reserved goes to false.

Rule 2 · The state has to be COHERENT with the operation

A sale cannot close a rental listing, nor the other way round. If operation is a rental, sold is rejected; if it is a sale, rented is rejected.

{ "field": "operationStatus",
  "rule": "incoherent",
  "value": { "sold": true, "operation": 2 },
  "detail": "`sold` significa que la operación CERRÓ, y esta propiedad es de Alquiler: una venta no puede cerrar un aviso de Alquiler. `sold` cierra una venta o una permuta. Si lo que querés decir es otra cosa, revisá `operation`." }

`operation`	Closes with
`1` Sale · `4` Barter	`sold`
`2` Rental · `3` Temporary rental	`rented`

reserved and suspended are compatible with any operation: reserving and suspending apply to everything.

And on 5 Transfer, 6 Share and 7 Auction we validate nothing: their family is ambiguous and we would rather not reject you over an interpretation of ours.

If you send two states on, you get ONE problem, not two. With two of them on there is no way to know which one was meant to be coherent, so we tell you the cause (exclusive) and not the consequence.

The PUBLICATION's state

Field	What it says
`suspended`	The listing does not show, even though the operation is still open

It is another axis: it says nothing about the operation. A suspended listing can go back to showing without anything having happened to the sale or the rental.

⚠️ But it shares rule 1: if you declare suspended, you cannot also declare sold.

When they are applied

On publishing, inside the same PUT …/publication/{portal}. There is no extra call for you to make.

It is an extra call against your client's quota, on our side: writing the state is a separate operation against the portal. A property without a declared state does not spend it.

And they are applied after the listing exists: the state is written onto a published listing.

What you get back

{ "status": "published", "portal": "argenpropapi", "paId": "01M41AQ…",
  "operationStatus": {
    "field": "sold", "axis": "commercial",
    "applied": true, "portalState": "vendido", "reason": null } }

Field	What it is
`field`	The state your object declared
`axis`	`commercial` = the operation's axis · `operational` = the publication's
`applied`	Whether the portal accepted it
`portalState`	What the portal calls it
`reason`	Why it was not applied, if `applied` is `false`

The field only appears if your object declared a state. Otherwise it does not come — it does not come as null.

applied: false does NOT mean the publication failed. The listing was published; what was not written is the state, and reason says why:

`reason`	What happened	What to do
`portal_sin_soporte`	that portal does not have that state	nothing: that is how it is, and the table is below
a portal code	the portal rejected the change	read it: it is the same kind of code as on publishing

🔴 Declaring a state HIDES the listing

On Argenprop, any of the four states leaves the listing not visible on the portal. That is correct —a sold property should not show as available— but it is worth knowing: you publish with sold: true, you get 200, and the listing does not show.

What you declare	How it ends up on the portal	Shows
nothing	`VIGENTE`	yes
`reserved`	`RESERVADO`	no
`sold`	`VENDIDO`	no
`rented`	`ALQUILADO`	no
`suspended`	`SUSPENDIDO`	no

And what matters for your integration: we still count it as published, all four of them.

"remoteStatus": "published",
"remote": { "estadoPortal": "VENDIDO", "visible": false }

The state on the portal tells you with the portal's own name, so you can tell "it was sold" apart from "it went down". If we treated it as not published, every retry of yours would try to republish a listing that is perfectly fine.

How to undo it

No state is final. Publish again with all four fields off and the listing shows again — including from sold or rented.

{ "code": "CMT-0014", "type": 1, "operation": 1, "sold": false }

There is no separate method for this: the same PUT …/publication/{portal} does it.

What each portal supports

Portal	The operation's state	The publication's state
Argenprop	✅	✅
Zonaprop	—	—
Cabaprop	—	—
MercadoLibre	—	—

A portal that does not support it is not an error. You publish anyway, the listing goes out, and the response tells you the state did not travel:

"operationStatus": { "field": "sold", "applied": false, "reason": "portal_sin_soporte" }

So you can send the same object to all four portals without branching your code.

Today only Argenprop supports the operation axis, and it is the only one of the four that has it. If you need this on another portal, write to dev@mapaprop.com: it helps us prioritise it.

Developments do not carry a state

A development is many listings, so the state does not apply there. If a unit sells, what applies is the state of that unit.

Publish to a portal — the PUT where this is applied
Check the state on the portal — what the portal says about the listing
The publication key — the per-portal data
Verify first — where both rules are rejected