Cambios de la API
Esta página existe para una sola cosa: que un cambio nuestro no te lo encuentres en producción.
Acá va lo que te afecta — un campo que se fue, uno nuevo, un comportamiento que cambió. Lo que no te afecta no entra, así que esta lista es corta a propósito y vale la pena leerla entera.
La API no cambia de versión: property-v1 es la superficie y se queda. Lo que cambia son cosas
puntuales adentro, y por eso las entradas van con su fecha y no con un número. Si tu código
funciona hoy, la fecha de la última entrada te dice desde cuándo.
Cómo leer cada entrada:
| 🔴 Rompe | si lo estabas usando, tu código deja de funcionar. Siempre dice qué poner en su lugar |
| 🟢 Suma | algo nuevo. No tenés que hacer nada; está acá para que sepas que existe |
| 🔧 Arreglo | algo que no funcionaba y ahora sí. No tenés que cambiar nada |
📧 Un cambio que rompe se avisa por mail, con 30 días de anticipación
No tenés que suscribirte a nada ni revisar esta página todos los días. Cuando un cambio 🔴 esté decidido, te escribimos al mail de la aplicación registrada al menos 30 días antes de que salga a producción, diciendo qué cambia, qué poner en su lugar y la fecha exacta.
En esos 30 días la API sigue funcionando como hoy. Si el plazo no te alcanza, escribinos: lo hablamos antes de mover nada.
| 🔴 Rompe | mail con 30 días de anticipación, y recién después sale |
| 🟢 Suma · 🔧 Arreglo | no avisamos por mail: no te obligan a hacer nada. Aparecen acá cuando salen |
Si tu mail de contacto cambió, avisanos a dev@mapaprop.com con tu
appId — es la dirección a la que vamos a escribir.
Las entradas del 21 de octubre de 2026 son anteriores a este compromiso y salieron el mismo día. De acá en adelante, un 🔴 se anuncia antes.
21 de octubre de 2026
🔴 remote.publicado ya no viaja — usá remoteStatus
Afecta a: consultar el estado de un aviso o de un desarrollo, en todos los portales.
El veredicto "¿está publicado?" viajaba en dos lugares: remoteStatus y remote.publicado. Era el
mismo dato, y dos campos que pueden contradecirse son peores que uno.
- if (r.remote.publicado) { … }
+ if (r.remoteStatus === 'published') { … }
remoteStatus dice lo mismo, es el mismo campo en todos los portales, y vale igual para avisos y para
desarrollos. Los valores son published, unpublished o null (el portal no nos dio con qué
decidir). El cuándo sigue en remote.unpublishedAt.
⚠️ Si leías publicado en un desarrollo de Zonaprop, es el mismo cambio:
la página del desarrollo ya lo dice así.
🔴 Argenprop: tres campos del estado cambiaron de nombre
Afecta a: GET …/publication/argenpropapi — el bloque remote.
Los nombres de Argenprop estaban en castellano y los de Zonaprop en inglés, para los mismos conceptos. Si soportabas los dos portales, tenías que escribir dos lecturas para cada pregunta.
| Antes | Ahora | Qué es |
|---|---|---|
remote.estadoPortal | remote.publicationState | el estado tal como lo dice el portal: VIGENTE · SUSPENDIDO · HISTORICO · RESERVADO · VENDIDO |
remote.puntos | remote.points | los puntos de ese aviso |
remote.idAviso | remote.portalItemId | el id que el portal le dio al aviso |
Ahora los dos portales usan los mismos nombres — cada uno con sus propios valores, que siguen siendo
los del portal. remote.visible no cambió.
🟢 Argenprop: remote.url ya trae la dirección pública del aviso
Afecta a: GET …/publication/argenpropapi.
Venía siempre en null. Ahora llega armada (https://www.argenprop.com/aviso--20722329), igual que
en Zonaprop. No hace falta que la construyas vos: si el portal cambia su formato, la corregimos
de un lado.
Sigue viniendo en null en los dos casos que siempre dijimos: si todavía no tenemos el id del portal,
o si no podemos armarla con certeza para el país de la propiedad.
🔧 Argenprop: las unidades de un desarrollo ahora se asocian bien
Afecta a: PUT /developments/{paId}/publication/argenpropapi.
La asociación de unidades devolvía un fallo por cada una ("la unidad no existe") aunque las unidades
estuvieran publicadas. Era nuestro, y ya está corregido: podés referenciarlas en units[] con el
código que vos les pusiste o con su paId, los dos funcionan.
🔧 Menos 503 al publicar un desarrollo grande
Afecta a: PUT /developments/{paId}/publication/{portal}.
Cuando el portal tardaba en responder una de las llamadas internas, la publicación entera se quedaba
sin tiempo y recibías un 503 sin detalle. Ajustamos cuánto esperamos cada una, así que ahora el
lote termina y lo que falló te vuelve por unidad, con su motivo — que es lo que la respuesta
siempre prometió.
No hace falta reintentar varias veces: si una unidad falla, el motivo está en la respuesta.
📘 Aclaración: publicar un desarrollo no es igual en los dos portales
No es un cambio de la API — es algo que la documentación decía mal, y conviene revisarlo si escribiste tu flujo leyéndola:
| Zonaprop | Argenprop | |
|---|---|---|
| Las unidades | viajan dentro de la publicación del desarrollo | ya tienen que estar publicadas: el desarrollo las toma |
| Llamadas | una | una por unidad, y después la del desarrollo |
El flujo corregido, con el cupo de cada caso: publicar un desarrollo.