DEVELOPING

When something does not work

The order below is not arbitrary: it goes from free to expensive, and from what you can see yourself to what we have to look at. The first two steps solve most cases and spend nothing from your client's allowance.

The order

1 · read the full error                 free — and it almost always says which step is missing
2 · check the object                    free — POST /properties/verify
3 · read what we have stored            free — GET /properties/{paId}
4 · ask the portal                      costs 1 call
5 · write to us                         with the reference from step 1

1 · The full error, not just the code

Our errors are written to say what to do, not just that something failed. Besides the code they carry a description and, where relevant, the name of the field or the portal.

The most important part: one of our errors tells you whether the problem is yours (something in what you sent) or from the previous step (the record is missing, the connection is missing). If it says the account needs connecting, it is not a permissions problem with your token.

2 · Check the object (free)

POST /properties/verify with the same object that failed. It tells you, portal by portal, what is missing. It asks the portal nothing, so it spends no allowance and does not depend on the portal being up.

It separates two things worth not mixing up:

What is missing in the object → that is within your control.
What is missing from the account (the plan, the branch) → that comes from the connection, not from the property.

What you see	Where to start
"I published and I do not see the listing"	The portal can take a while to show it. Step 4 tells you whether it already has it; if it says yes, that is the portal's publication timing, not an integration problem
The plan I asked for is not available	The publish response tells you which ones your client does have. If that is not what you expected, refresh the plans against the portal: one may have been used up or expired
A `403`	Look at which scope it says is missing. If it names a portal, your token is not enabled for that portal — which is different from not being able to read or write
It says the account is not connected	Request the client's record (free) and look at the state of their connections. Your client may have disconnected it on the portal's side
An empty list of enquiries	Before assuming there are none, check which mode that portal supports: it may be that enquiries there are not requested but arrive on their own
Something you sent does not show up	Check it (step 2): if the portal does not support that field, we tell you there instead of discarding it silently

What to rule out before writing to us

Did you check the object? It is free and it answers most cases.
Does the error name an earlier step (record, connection)? Then the problem is not where you are looking.
Are you using the identifier we returned, and not one of yours, where the route asks for ours?
Does the portal support that? Not all of them support everything, and what is not supported we say without spending allowance.

5 · Write to us

dev@mapaprop.com. What speeds up the answer the most:

The reference that came with the error. With that we find your exact call in our records — it is the difference between looking at the case and asking you to reproduce it.
What you expected and what happened, in that order.
The clientRef and the property's identifier.

Do not send us your token or your client's credential. We do not need them to diagnose, and if you sent them by mistake, tell us so we can help you rotate them.

Best practices — the complete flows
Checking — step 2, the most profitable one
Publication — what each portal supports

When something does not work

The order

1 · The full error, not just the code

2 · Check the object (free)

3 · What we have stored (free)

4 · Asking the portal (1 call)

The cases that come up most

What to rule out before writing to us

5 · Write to us