Property API
Publish your properties to several real estate portals with a single model. Mapaprop has already implemented each portal's API, so instead of integrating them one by one you send us the object once and we translate it.
📋 Before you go live, check API changes — and every so often afterwards. It is the list of what changed, with its date: a field that is gone, a new one, a different behaviour. It is short on purpose: only what forces you to do something goes in.
property-v1 does not change version, so that is the only way to know whether something moved
since you wrote your integration.
Before anything else: your credentials
To call any endpoint in this section you need an access token, and for that your application has to be registered.
Getting started with OAuth2 — you register your application, we give you your credentials, and with them you obtain the token
Three things from there worth having clear before going on:
| The token expires | after 14 days. An unexpected 403 is usually that, not a permissions problem |
| You do not send an identifier for your app | it travels inside the token and we resolve it. There is nothing to configure and no id to store |
| Your app and each client are two levels | today the only thing configured at your app's level are webhooks. Everything else — the client's record, their portal accounts, their properties — goes per client, with the x-client-ref header |
There are two ways to get here, and the token is obtained differently in each one.
If you are an integrator —your app publishes the inventory of other real estate agencies— you
register your application and obtain the token with client_id/client_secret, as described
above.
If you are a Mapaprop client and you want to automate your own account, you register nothing: you contract Property API and activate your API Token with one click from Settings > API Token. It is the same token for all your API services, and it does not expire. How to do it: Property API Token.
Best practices — the complete flows
This page lists the API by resource: what each endpoint does. If what you need is the order —what comes before what, what you decide at each step and what it costs— that is the other half of the documentation, and it is worth starting there.
Best practices — the four rules that apply to every flow: what is done once and what every time, what is free and what spends allowance, what to store on your side and what happens when you retry
Setting up a client — once per client, and the only real fork: link or credential, depending on the portal
Publishing a listing — the base case, end to end
Publishing a development — the units come before the development; here the order is the content
Receiving enquiries — the only flow where you do not push, you receive
Taking things down — taking a listing down, disconnecting an account and deleting a client are three different things
When something does not work — where to start looking, from free to expensive
1. Start here
In this order: first you understand the model, then you build the object and test it, and only then do you declare your client and connect their portal accounts. Without a connected account there is no publishing.
The property model — why the keys are the same in every country
The property JSON object — the fields, their rules and which ones are required
POST /properties/verify — check your object before publishing. It creates and publishes nothing
Clients — declare it once; its properties inherit the name, phone and email
Connect their portal accounts — Argenprop, Cabaprop and MercadoLibre: you store the token you already have
Connect with a link — Zonaprop: your client authorizes from a link you send them
Check and disconnect — the status of your client's connections, and unlinking
POST /properties — create: saves the property, returns the paId and stores your images on our servers
1B. Real estate developments
A building under construction, a gated community, a tower being built. They are sent through the same endpoint as a property —there is no new model to learn— and we return the calculated figures for its units: availability, sales and rentals kept apart, square metres, price range by currency and the breakdown by unit type.
The development JSON object — the development group, its fields and how units are declared
Verify and create a development — the flow, the order that works and what we validate on top
developmentStats — the calculated figures for its units, field by field
2. Catalog
The reference data you need to map your system against ours. You download it once and store it: these are not endpoints to call on every property creation.
Zones — how to map yours against ours, and what format the code has
GET /property-catalog-v1/zones — the complete list for a country, paginated
The cascade: zones1 / zones2 / zones3 — the same zones, one level at a time
GET /property-attributes — types, operations, statuses and amenities
3. Publishing
Publish to a portal — publish an already uploaded property to your client's portal
Unpublish from a portal — take the listing down. It is idempotent
Check the status on the portal — the listing URL, whether it is still online and the visits. ⚠️ spends one call of the client's quota
The publication key — the per-portal configuration
GET /properties/{paId} — look up a property
GET /properties — list every one of a client's, with each portal's status
PUT /properties/{paId} — modify: full replacement, with a diff of what changed
DELETE /properties/{paId} — delete. It does not take down your listings on the portals
4. Leads
Leads — what a lead is, the object we return, the shared allowance and why we do not store them
Enquiries for the whole account — a single call brings those of every listing. It is the normal path
Enquiries for a single property — those of one specific listing
Which mode each portal supports — whether on that portal enquiries are requested or arrive on their own. Read it instead of assuming