Los estados que viajan con la propiedad
Hay dos cosas distintas que el objeto puede declarar, y conviene no confundirlas:
| Eje | Qué dice | Campos |
|---|---|---|
| El estado de la OPERACIÓN | la operación cerró: se reservó, se vendió, se alquiló | reserved · sold · rented |
| El estado de la PUBLICACIÓN | el aviso no se muestra, aunque la operación siga abierta | suspended |
Los dos viajan dentro del objeto y se aplican cuando publicás. No hay un método aparte.
{ "code": "CMT-0014", "type": 1, "operation": 1, "sold": true }
El alcance de esta página son esos dos ejes. Si en el futuro aparece un tercero, va a tener su propia sección acá — no se mezcla con éstos.
El estado de la OPERACIÓN
| Campo | Qué dice |
|---|---|
reserved | La operación está reservada |
sold | Cerró como venta |
rented | Cerró como alquiler |
🔴 No dicen que la propiedad esté ocupada: dicen que la operación cerró. Es la distinción que gobierna las dos reglas de abajo.
Regla 1 · Uno o ninguno, nunca dos
Una propiedad tiene UN estado o ninguno — contando también suspended. Si mandás dos prendidos,
el objeto se rechaza en el verificador y en el alta, antes
de publicar nada.
{ "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." }
El caso que más se da: se reservó, después se vendió, y el sistema de origen dejó reserved
prendido. El estado correcto es sold, y reserved va en false.
Regla 2 · El estado tiene que ser COHERENTE con la operación
Una venta no puede cerrar un aviso de alquiler, ni al revés. Si operation es un alquiler,
sold se rechaza; si es una venta, rented se rechaza.
{ "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 | Cierra con |
|---|---|
1 Venta · 4 Permuta | sold |
2 Alquiler · 3 Alquiler Temporario | rented |
reserved y suspended son compatibles con cualquier operación: reservar y suspender valen para
todo.
Y en 5 Traspaso, 6 Compartir y 7 Remate no validamos nada: su familia es ambigua y
preferimos no rechazarte por una interpretación nuestra.
Si mandás dos estados prendidos recibís UN problema, no dos. Con dos prendidos no se puede saber
cuál debía ser coherente, así que te decimos la causa (exclusive) y no la consecuencia.
El estado de la PUBLICACIÓN
| Campo | Qué dice |
|---|---|
suspended | El aviso no se muestra, aunque la operación siga abierta |
Es otro eje: no dice nada de la operación. Un aviso suspendido puede volver a mostrarse sin que haya pasado nada con la venta o el alquiler.
⚠️ Pero comparte la regla 1: si declarás suspended, no podés declarar además sold.
Cuándo se aplican
Al publicar, dentro del mismo PUT …/publication/{portal}.
No hay una llamada extra que hacer de tu lado.
Sí es una llamada extra del cupo de tu cliente, del lado nuestro: escribir el estado es una operación aparte contra el portal. Una propiedad sin estado declarado no la gasta.
Y se aplican después de que el aviso existe: el estado se escribe sobre un aviso publicado.
Qué te contesta
{ "status": "published", "portal": "argenpropapi", "paId": "01M41AQ…",
"operationStatus": {
"field": "sold", "axis": "commercial",
"applied": true, "portalState": "vendido", "reason": null } }
| Campo | Qué es |
|---|---|
field | El estado que declaró tu objeto |
axis | commercial = el eje de la operación · operational = el de la publicación |
applied | Si el portal lo aceptó |
portalState | Cómo lo llama el portal |
reason | Por qué no se aplicó, si applied es false |
El campo sólo aparece si tu objeto declaró un estado. Si no, no viene — no viene en null.
applied: false NO significa que la publicación falló. El aviso se publicó; lo que no se
escribió es el estado, y reason dice por qué:
reason | Qué pasó | Qué hacer |
|---|---|---|
portal_sin_soporte | ese portal no tiene ese estado | nada: es así, y abajo está la tabla |
| un código del portal | el portal rechazó el cambio | leelo: es el mismo tipo de código que en el publish |
🔴 Declarar un estado OCULTA el aviso
En Argenprop, cualquiera de los cuatro estados deja el aviso no visible en el portal. Es
correcto —una propiedad vendida no debería mostrarse como disponible— pero conviene saberlo:
publicás con sold: true, recibís 200, y el aviso no se ve.
| Lo que declarás | Cómo queda en el portal | Se ve |
|---|---|---|
| nada | VIGENTE | sí |
reserved | RESERVADO | no |
sold | VENDIDO | no |
rented | ALQUILADO | no |
suspended | SUSPENDIDO | no |
Y lo que importa para tu integración: nosotros lo seguimos contando como publicado, los cuatro.
"remoteStatus": "published",
"remote": { "estadoPortal": "VENDIDO", "visible": false }
El estado en el portal te lo dice con el nombre del portal, así que podés distinguir "se vendió" de "se cayó". Si lo tratáramos como no publicado, cada reintento tuyo intentaría republicar un aviso que está perfectamente bien.
Cómo se vuelve atrás
Ningún estado es definitivo. Volvé a publicar con los cuatro campos apagados y el aviso vuelve a
verse — también desde sold o rented.
{ "code": "CMT-0014", "type": 1, "operation": 1, "sold": false }
No hay un método aparte para esto: lo hace el mismo
PUT …/publication/{portal}.
Qué soporta cada portal
| Portal | Estado de la operación | Estado de la publicación |
|---|---|---|
| Argenprop | ✅ | ✅ |
| Zonaprop | — | — |
| Cabaprop | — | — |
| MercadoLibre | — | — |
Un portal que no lo soporta no es un error. Publicás igual, el aviso sale, y la respuesta te dice que el estado no viajó:
"operationStatus": { "field": "sold", "applied": false, "reason": "portal_sin_soporte" }
Así podés mandar el mismo objeto a los cuatro portales sin ramificar tu código.
Hoy sólo Argenprop soporta el eje de la operación, y es el único de los cuatro que lo tiene. Si necesitás esto en otro portal, escribinos a dev@mapaprop.com: nos ayuda a priorizarlo.
Los desarrollos no llevan estado
Un desarrollo son muchos avisos, así que el estado no se aplica ahí. Si una unidad se vende, lo que corresponde es el estado de esa unidad.
Relacionado
- Publicar en un portal — el
PUTdonde esto se aplica - Consultar el estado en el portal — lo que el portal dice del aviso
- La clave
publication— los datos por portal - Verificar antes — donde las dos reglas se rechazan