DEVELOPING

Check the status on the portal

GET /property-v1/properties/{paId}/publication/{portal}

This is how you find out how the listing is doing on the other side: whether it is still online, what its public URL is, how many visits it got, and whether the portal recorded any error.

This call spends one call of the client's monthly quota on the portal, just like publishing. If you only need the last known status, GET /properties/{paId} gives it to you at no cost.

curl https://property-api.mapaprop.com/property-v1/properties/01M41AQNXYG4W4SEEEEPHEDNX4/publication/zonapropapi \
  -H "Authorization: Bearer $TOKEN" \
  -H "x-client-ref: cliente-42"

{
  "paId": "01M41AQNXYG4W4SEEEEPHEDNX4",
  "portal": "zonapropapi",
  "remoteStatus": "unpublished",
  "inSync": false,
  "remote": {
    "portalItemId": 60321762,
    "url": "https://www.zonaprop.com.ar/propiedades/clasificado/-60321762.html",
    "publicationState": "OFFLINE",
    "processingState": "PROCESADO",
    "onlineAt": "2026-10-03T17:14:06.000Z",
    "offlineAt": "2026-10-03T04:00:00.000Z",
    "createdAt": "2026-10-03T17:14:05.000Z",
    "modifiedAt": "2026-10-03T17:14:28.000Z",
    "visits": 0,
    "errors": [],
    "warnings": [],
    "imagesStatus": [],
    "exists": true,
    "checkedAt": "2026-10-03T18:42:57.716Z"
  },
  "quota": { "remaining": 1443, "limit": 1500 }
}

The listing URL

remote.url is where the published listing can be seen. It cannot be built on your side: it uses the portal's internal id (remote.portalItemId), which is different from the code you publish with.

remote.url comes back as null if we do not have the portal's id yet, or if we cannot build the URL with certainty for the property's country. We do not build an approximate one: a link that leads somewhere else is worse than no link at all.

The two reads: one free and one fresh

	What it returns	Quota
`GET /properties/{paId}`	the last status we already had, in `published.{portal}.remote`	free
`GET …/publication/{portal}` (this page)	asks the portal right now	1 call

remote.checkedAt is there to help you choose between the two: it tells you how old the stored data is. If that is good enough, there is no need to ask again.

If you walk your whole inventory checking property by property, you spend one call for each one. With 400 properties that is 400 of the month's 1500 calls. Read the stored status first and only check what you genuinely need fresh.

`remoteStatus` and `inSync`

remoteStatus is the listing's status, and this call updates it with whatever the portal says.

The portal's `publicationState`	`remoteStatus` ends up as
`ONLINE`	`published`
`OFFLINE`	`unpublished`
the listing does not exist on the portal	`unpublished`
a value we do not recognise	left untouched

inSync answers the question that matters: is the listing the way you left it?

`inSync`	What it means	What to do
`true`	the portal matches what you expected	nothing
`false`	it changed without you asking — it dropped, or the plan expired	publish again if you want it up
`null`	the portal returned a status we cannot interpret	look at `remote.publicationState` and write to us

We do not republish on our own. If the listing dropped, we tell you with inSync: false and the decision is yours: you may not want it up any more.

The other `remote` fields

Field	What it is
`portalItemId`	the id the portal gave the listing. It is what forms the URL
`publicationState`	`ONLINE` / `OFFLINE` — whether the listing is live
`processingState`	which stage of the portal's processing it is at (e.g. `PROCESADO`)
`onlineAt` · `offlineAt`	when it went up and when it was taken down
`createdAt` · `modifiedAt`	on the portal's side, not yours
`visits`	visits the portal recorded. `null` if it does not report them
`errors` · `warnings`	exactly as the portal sends them, untranslated
`imagesStatus`	what the portal did with each image
`exists`	`false` if the listing is not on the portal
`checkedAt`	when we asked

errors may carry entries even when publishing went fine: they are notes the portal leaves on its own. They go uninterpreted because the portal's wording is more precise than any translation of ours.

Response codes

Code	What happened	What to do
`200`	the listing's status	—
`403`	your token does not have the `{portal}:publish` scope	write to us to enable it
`404`	that property is not in your inventory	check the `paId` and the `x-client-ref`
`409`	the account is not connected to the portal	request a connection link
`501`	we cannot check the status on that portal yet	the portal comes in `portal`
`502`	we could not reach the portal	try again; we change nothing on your side

A 501 does not mean the portal does not exist: you may be publishing to it perfectly well and what is missing is this check. Today it is available on Zonaprop.

Publishing to portals — the three methods of the same endpoint
PUT publish · DELETE unpublish
GET /properties/{paId} — the read that does not spend quota

Check the status on the portal

The listing URL

The two reads: one free and one fresh

remoteStatus and inSync

The other remote fields

Response codes

Related

`remoteStatus` and `inSync`

The other `remote` fields