Which mode each portal supports

GET /property-v1/leads/capabilities

Enquiries do not arrive the same way on every portal: on some you request them and on others they reach you on their own. And that is decided by each portal, not by us.

This method tells you as data, so you do not have to keep it written in your code.

It is the only leads method that does NOT require {portal}:leads. It requires property-api-catalog — the same one used for zones and attributes. That is because it speaks about all portals at once: requiring the one for a single portal would be arbitrary, and requiring all four would make it unreadable for you. If you already consume the zones catalog, you do not need to request anything new.

curl "https://property-api.mapaprop.com/property-v1/leads/capabilities" \
  -H "Authorization: Bearer $TOKEN"

It takes no parameters. It looks at none of your clients' accounts and spends nobody's quota.

The three modes

They are named after who triggers them, which is the only difference that changes your work:

Mode	Who triggers it	What you have to do
`pull`	you, whenever you want	request the enquiries with by account or by property
`pushFromPortal`	the portal notifies us, and we forward it to you	have an endpoint of your own and verify our signature
`pushFromMapaprop`	we query and push it to you	the same: your endpoint and the signature

Both push modes are not available on any portal yet. When they are, this method will say so — and that is exactly why it exists.

The response

{
  "portals": {
    "zonapropapi": {
      "pull": { "available": true, "byAccount": true, "byProperty": true, "quotaShared": true },
      "pushFromPortal": { "available": false },
      "pushFromMapaprop": { "available": false }
    },
    "argenpropapi": {
      "pull": { "available": false },
      "pushFromPortal": { "available": false },
      "pushFromMapaprop": { "available": false }
    },
    "cabapropapi": {
      "pull": { "available": false },
      "pushFromPortal": { "available": false },
      "pushFromMapaprop": { "available": false }
    },
    "mercadolibreapi": {
      "pull": { "available": false },
      "pushFromPortal": { "available": false },
      "pushFromMapaprop": { "available": false }
    }
  }
}

What each field means


`available`	whether that mode can be used today on that portal
`byAccount`	whether you can fetch the ones for the whole account in a single call — the normal path
`byProperty`	whether you can fetch the ones for a specific listing
`quotaShared`	whether enquiries spend the same monthly quota as publishing and as checking the listing status

byAccount, byProperty and quotaShared appear only when pull.available is true: on a portal without pull they describe nothing, and sending them as false would read as if the service existed and were switched off.

quotaShared: true means a query can leave you without quota to publish. That is the case with Zonaprop: there is a single monthly cap, shared by publishing, checking the status and fetching enquiries. How the Zonaprop quota works.

How to use it

Read it once when your integration starts up and keep the result; read it again every now and then. There is no need to check it before every enquiries request.

What it saves you:

Not writing into your code which portal is queried and which one notifies. The day a portal gains a new mode, your integration finds out on its own.
Not discovering it by trial. If you request enquiries from a portal that does not offer them yet, the response is an honest 501 telling you which of the two services is missing — but you found out after having built the call.

A portal that does not appear in the list is not an unsupported portal: it is a portal that does not exist in this API. The ones that support nothing yet do appear, with everything set to false.

Errors

	When	What to do
401	the token is missing, expired or not valid	check the `Authorization`
403	you are missing the `property-api-catalog` scope	ask us to grant it to you. It is not `{portal}:leads`: that one does not enable this method