API changes
This page exists for one thing only: so that a change of ours does not meet you in production.
What goes here is what affects you — a field that is gone, a new one, a behaviour that changed. What does not affect you does not go in, so this list is short on purpose and worth reading in full.
The API does not change version: property-v1 is the surface and it stays. What changes are
specific things inside it, which is why entries carry their date and not a number. If your code
works today, the date of the latest entry tells you since when.
How to read each entry:
| 🔴 Breaks | if you were using it, your code stops working. It always says what to put instead |
| 🟢 Adds | something new. You do not have to do anything; it is here so you know it exists |
| 🔧 Fix | something that did not work and now does. You do not have to change anything |
📧 A breaking change is emailed, 30 days in advance
You do not have to subscribe to anything or check this page every day. Once a 🔴 change is decided, we email the registered application's address at least 30 days before it goes to production, telling you what changes, what to put instead, and the exact date.
During those 30 days the API keeps working as it does today. If that window is not enough for you, write to us: we talk it through before moving anything.
| 🔴 Breaks | email 30 days in advance, and only then it ships |
| 🟢 Adds · 🔧 Fix | no email: they do not force you to do anything. They show up here when they ship |
If your contact address changed, let us know at dev@mapaprop.com with
your appId — that is where we will write.
The 21 October 2026 entries predate this commitment and shipped the same day. From now on, a 🔴 is announced beforehand.
21 October 2026
🔴 remote.publicado no longer travels — use remoteStatus
Affects: checking the status of a listing or a development, on every portal.
The "is it published?" verdict travelled in two places: remoteStatus and remote.publicado. It
was the same fact, and two fields that can contradict each other are worse than one.
- if (r.remote.publicado) { … }
+ if (r.remoteStatus === 'published') { … }
remoteStatus says the same thing, it is the same field on every portal, and it holds for listings
and developments alike. The values are published, unpublished or null (the portal gave us
nothing to decide with). The when is still in remote.unpublishedAt.
⚠️ If you were reading publicado on a Zonaprop development, it is the same change:
the development page already says it this way.
🔴 Argenprop: three status fields were renamed
Affects: GET …/publication/argenpropapi — the remote block.
Argenprop's names were in Spanish and Zonaprop's in English, for the same concepts. If you supported both portals, you had to write two readers for every question.
| Before | Now | What it is |
|---|---|---|
remote.estadoPortal | remote.publicationState | the state exactly as the portal says it: VIGENTE · SUSPENDIDO · HISTORICO · RESERVADO · VENDIDO |
remote.puntos | remote.points | the points of that listing |
remote.idAviso | remote.portalItemId | the id the portal gave the listing |
Both portals now use the same names — each with its own values, which are still the portal's.
remote.visible did not change.
🟢 Argenprop: remote.url now carries the listing's public address
Affects: GET …/publication/argenpropapi.
It always came back null. It now arrives built (https://www.argenprop.com/aviso--20722329), just
like on Zonaprop. You do not need to construct it: if the portal changes its format, we fix it in
one place.
It still comes back null in the two cases we always stated: if we do not have the portal's id yet,
or if we cannot build it with certainty for the property's country.
🔧 Argenprop: a development's units now associate correctly
Affects: PUT /developments/{paId}/publication/argenpropapi.
Associating units returned a failure for each one ("the unit does not exist") even when the units
were published. It was ours, and it is fixed: you can reference them in units[] with the code you
gave them or with their paId — both work.
🔧 Fewer 503s when publishing a large development
Affects: PUT /developments/{paId}/publication/{portal}.
When the portal was slow to answer one of the internal calls, the whole publication ran out of time
and you got a 503 with no detail. We adjusted how long we wait for each one, so the batch now
finishes and whatever failed comes back per unit, with its reason — which is what the response
always promised.
There is no need to retry several times: if a unit fails, the reason is in the response.
📘 Clarification: publishing a development is not the same on both portals
This is not an API change — it is something the documentation got wrong, and it is worth reviewing if you wrote your flow by reading it:
| Zonaprop | Argenprop | |
|---|---|---|
| The units | travel inside the development's publication | have to be published already: the development takes them |
| Calls | one | one per unit, and then the development's |
The corrected flow, with the quota cost of each case: publishing a development.