DEVELOPING

Publish to a portal

Once the property is uploaded and the portal account connected, this publishes it.

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

You do not send the property again: we already have it, and we publish it exactly as it was stored. We translate it to the portal's format.

Portal	`{portal}` value	Status
Zonaprop	`zonapropapi`	available
Argenprop, Cabaprop, MercadoLibre	—	coming soon

Requires the {portal}:publish scope — for example zonapropapi:publish. It is different from :connect: you may be allowed to connect accounts for a portal and not to publish on it.

Before publishing

Three things, in this order:

Your client's record — Clients
Their portal account connected — Connect with a link
The property uploaded, with its paId — Creating properties

The call

Field	Type	Required	Description
`plan`	string	depends on the portal	The publication plan. Overrides the one set in `publication` inside the object

curl -X PUT https://property-api.mapaprop.com/property-v1/properties/01M3PTZ8YBMM5DSNW03WP8VD9E/publication/zonapropapi \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -H "x-client-ref: cliente-42" \
  -H "Content-Type: application/json" \
  -d '{ "plan": "SUPERDESTACADO" }'

Response 200:

{
  "status": "published",
  "portal": "zonapropapi",
  "paId": "01M3PTZ8YBMM5DSNW03WP8VD9E",
  "plan": "SUPERDESTACADO",
  "quota": { "remaining": 1493, "limit": 1500 }
}

You can also leave the plan fixed in the object, under publication. If you send both, the one in this call wins: that way you can change plans without rewriting the property.

Calling again UPDATES, it does not duplicate

Publishing the same property twice does not create two listings. The second call updates the existing one. You can retry safely: if a call failed and you do not know whether it went through, call again.

It is the most important property of this endpoint, and the reason there is no separate "create" and "update": a single operation, and the result depends on whether the listing already exists.

When it cannot be published: `422`

It is not an error in your call — a piece of data is missing. That is why there are two separate lists:

{
  "error": "not_publishable",
  "detail": "La propiedad no se puede publicar en este portal todavía.",
  "blockers": [
    { "field": "title", "kind": "missing", "message": "Falta el título" }
  ],
  "accountBlockers": [
    { "field": "options.zoneNaventId", "kind": "missing",
      "message": "La zona de la propiedad no tiene mapeo guardado en Zonaprop" }
  ]
}

List	What it means	Who resolves it
`blockers`	a piece of property data is missing	you: fix the object and try again
`accountBlockers`	something about the account at the portal is missing (unmapped zone, plan, branch)	resolved once, and it works for every property of that client

They are separate because the fix is different. If you are looking at accountBlockers, reviewing the property JSON will get you nowhere: it is fine.

You can anticipate almost every blocker with POST /properties/verify, which neither creates nor publishes anything.

Response codes

Code	What happened	What to do
`200`	Published	—
`400`	The portal is not available yet, or the body is not valid JSON	Check the `{portal}` value
`403`	Your token lacks the `{portal}:publish` scope	Write to us to enable it
`404`	That property does not exist for this client	Check the `paId` and the `x-client-ref`
`409`	The account is not connected to the portal	Request a connection link
`409`	The client is deactivated (`customer_not_active`)	Reactivate it with `POST /property-v1/customers` — see Clients
`422`	A piece of data is missing	See above
`502`	The portal rejected the publication, or did not respond	See below

The `502`, which has two flavours

{ "error": "portal_rejected",
  "detail": "No pudimos alcanzar al portal. El aviso PUEDE haberse publicado: volvé a intentar, la operación es idempotente y no duplica.",
  "portalResponse": null }

The portal rejected it → portalResponse carries its response as-is. The reason is there.
It did not respond → the detail says so, and it may have been published anyway. Retrying is safe: it does not duplicate.

We do not tell you "it was not published" when we do not know.

Unpublishing

Coming soon. DELETE /property-v1/properties/{paId}/publication/{portal} will take the listing down at the portal. Write to dev@mapaprop.com if your integration needs it.

In the meantime, your client can take the listing down from the portal's own panel.

Portal specifics

Zonaprop: the plan is required and each publication consumes your client's monthly quota — Monthly quota and limits

The publication key — what to configure inside the object
Connect with a link — connecting the portal account
POST /properties/verify — anticipating the blockers