Taking things down
These are three different operations and they get confused often. The difference matters because one of them affects what the public sees and the other two do not.
| You want to… | You call | Does the listing leave the portal? |
|---|---|---|
| take a listing down from a portal | DELETE …/publication/{portal} | yes |
| disconnect your client's account | disconnect | no |
| delete your client's record | DELETE /customers | no |
🔴 The rule, and it is a decision of ours, not a limitation
We never take a listing of your client's down on our own initiative. Not when disconnecting their account, not when deleting their record, not if they stop using the service.
That listing is published with your client's account on the portal, and the decision to take it down is theirs. We disconnect what is ours; their listing remains their listing.
What we do do when disconnecting is cut off our own access: we stop being able to publish or update on their behalf.
⚠️ This matters for your design. If your app offers "unlink from Mapaprop" and you assume that cleans up the portals, your client's listing will stay up — with the data frozen as of the last day you updated it. If you want it taken down, take it down explicitly first.
The order, if you want to leave everything clean
1 · take the listings down DELETE …/publication/{portal} ← one per property and portal
2 · disconnect the account
3 · delete the record (if applicable)
Skipping step 1 does not fail: it disconnects all the same and the listings stay published. That is why the order is a recommendation, not a requirement the system enforces.
Taking a listing down
DELETE …/publication/{portal} takes that listing
down from that portal.
- It is idempotent: if it was already gone, it answers fine all the same. You do not have to keep track.
- It is per portal: if you published on three, that is three calls. Taking it down from one does not touch the others.
- It spends one call from your client's allowance, like publishing.
- The property still exists on our side: unpublishing is not deleting. You can publish it again whenever you want, with the same identifier.
Disconnecting the account
Disconnecting cuts off our access to the portal account. After that, publishing and updating are not possible until your client connects it again.
What we keep on purpose, and it is what makes reconnecting cheap:
- Which properties were published on which portal. On reconnecting, the state is recovered and corrected against what the portal actually says.
- The zone mapping. That data belongs to the system, not to the account: it is never deleted.
Deleting the client's record
DELETE /customers deletes what we hold about that client.
Their listings on the portals stay published — same rule as above.
It is the least reversible of the three: after deleting, setting that client up again means starting from scratch, portal connection included.
How each one answers if you get ahead of yourself
| If you… | |
|---|---|
| take down a listing that was already down | 200, no drama. It is idempotent |
| take down a listing on a portal you never published to | we tell you, and nothing is broken |
| disconnect an account that was not connected | we tell you, naming the portal |
| publish after disconnecting | the error says that account needs connecting, not "you lack permission" |
Related
- Unpublishing from a portal — the endpoint and its contract
- Checking and disconnecting · Deleting a client
- Setting up a client — the reverse path