Clients
Before uploading your first property, you declare the record of the client that owns it: their name, their contact details and their branch. You do it once per client and from then on their properties inherit it.
We say client and not "agency" on purpose: it can be a real estate agency, a developer, a rental
manager or an individual. The API calls it customer, and its id is your clientRef.
The four methods
| What it does | ||
|---|---|---|
POST | Declares the client and returns the customerId we assign to it | property-api-create |
GET | Returns what you declared | property-api-read |
PUT | Changes the details. It does not change the customerId | property-api-update |
DELETE | Deactivates the client. Reversible | property-api-delete |
All four go to the same route, /property-v1/customers, and the client you operate on is given by the
x-client-ref header — same as everywhere else in the API.
These details are the source of the name, phone, email and address published on every listing.
Why it is not on every property
An integrator asked for it, and he was right: you had to repeat the same client details on every upload, and they were the same for all 500 of its properties.
By declaring them once, new properties inherit them on their own and you never have to send them again.
customerId — we issue it
The customerId (MAPAPROP-PA-000002) is not yours to choose: we assign it when the record is
created, and it is the code that identifies that client to the portals.
The customerId never changes. The PUT does not change it, and a record that is deactivated and
reactivated comes back with the same one. If it changed, the listings your client already has
published would hang off a code that stopped existing.
Your clientRef is a different thing: it is your identifier, the one you use to tell us which
client you are talking about. We do not interpret it.
The lifecycle
POST → the client is declared, with its customerId
├── GET look it up
├── PUT change the details (the id is not touched)
└── DELETE deactivate ────┐
│
POST (again) ←─────────────────────────┘ reactivates it, with the SAME customerId
A repeated POST on a client that already exists does not duplicate anything nor issue another id:
it returns the one that is there, with created: false.
What happens if you do not declare it
| Endpoint | With no record |
|---|---|
POST /properties | 400 with rule: account_required |
POST /properties/verify | 200 — it is a tester: it simulates the client details with a placeholder and declares it in customerSource: "placeholder" |
That is why you can try your object on day one, before declaring anything.
What you can do with the declared record
The record is not just the contact its properties inherit: it is the client you later connect portals for and publish on behalf of.
| To | Go to |
|---|---|
| Connect their Zonaprop account | Connect with a link |
| Connect Argenprop, Cabaprop or MercadoLibre | Portal connections |
| See the status of their connections, or disconnect | Portal connections |
| Understand the Zonaprop monthly quota | Monthly quota and limits |
| Upload their properties | Uploading properties |
The code we assign here (MAPAPROP-PA-000123) is the one your client identifies with to the
portals. That is why the record comes first: without it no connection link can be issued.
There is no way to list your clients via the API yet. Each method operates on one clientRef at a
time, so the record of which clients you declared is yours to keep. If you need to enumerate them —
above all to know which ones are active and which are deactivated — write to dev@mapaprop.com and we
will prioritise it.