Mapaprop

Mapaprop

Besides being the system you are integrating with, Mapaprop is one of the destinations your property can end up in. And it is the only one you do not have to ask for.

If you are a Mapaprop customer and generated your token from the app (Mapaprop > App and Token), every property you load through this API is created in your account by itself. There is no step to ask for and no endpoint to call.

If your token did not come from a Mapaprop account —the case of an integrator publishing to portals for clients who are not customers of ours— none of this page applies to you: your properties live only in PropertyAPI and are published to the portals you connect.

The two things, which are not the same

This is the distinction worth being clear about before going on:

What it isWho triggers it
The creationthe property exists in your Mapaprop account, as if you had loaded it from the appby itself, without you asking
The publicationthat property goes live on your site and on the portalsyou, with PUT …/publication/{portal}

Being created does not mean being published. It sits in your account like any property loaded by hand, and publishing it is your decision — the same one you would make from the app.

When it happens

The creation is not instant, and there is a reason: the photos.

1 · POST /properties        we save the property and return the paId
2 · we fetch the images     we download them from wherever you keep them and host them ourselves
3 · creation in your account ← fires by itself when step 2 finishes

A property reaches your account with its photos already loaded, which is the only way it is useful. That is why it waits for the ingestion to finish instead of being created empty and completed later.

How you know it worked

In the mapaprop block, which travels both in the response to the POST and in the GET of the property:

{
  "mapaprop": {
    "state": "synced",
    "propertyId": 2619527,
    "branchId": 1,
    "message": "La propiedad existe en tu cuenta de Mapaprop con el id 2619527 (sucursal 1)…"
  }
}

The propertyId is the Mapaprop id, different from this API's paId. It is the one you use to find the property in the app.

statewhat happened
pendingit has not run yet: the image ingestion has not finished
syncedthe property exists in your account
rejectedsomething in the object could not be saved. The block names the field
blockedthe account is not in a fit state. We sort that out
exhaustedthe automatic retries ran out

The states, what to do with each one and how to retry are in Retry the creation.

Check before posting. POST /properties/verify is free and reviews the object against the same contract, so a value the creation could not save is something we tell you right then, instead of you finding out minutes later in the block.

What goes in with the property

Everything you sent in the object, in the same call:

The photoswith their rotation and their thumbnail, like a photo loaded from the app. The one you mark main becomes the main one
The blueprintone per property. It has to be an image, never a PDF
The videosthe platform link, not the file
The expenses and the taxeswith their currency and the payment period
The alternative prices"per week", "per season" and whichever you declare

If any of this fails and the property was created, the mapaprop block says so and the retry sends only what is missing — it does not create the property again.

Which branch it goes into

The one you declare in branchId. If you send none, it goes into the account's main branch — and the response tells you which one it ended up in, so you do not have to guess.

Your account's branches, with their ids, come from GET /branches.

Publishing on Mapaprop

Once created, it is published like any other destination, passing mapaprop where the route asks for {portal}:

PUT    /property-v1/properties/{paId}/publication/mapaprop
GET    /property-v1/properties/{paId}/publication/mapaprop
DELETE /property-v1/properties/{paId}/publication/mapaprop