POST /properties/verify

You send a property object and we answer three things:

1. Whether the object is valid according to Mapaprop's contract, and what it is missing if it is not.
2. What we understood of what you sent — how many fields we rebuilt from your attributes array.
3. Whether each portal could publish it, and when it could not, exactly what is missing and whose problem it is.

What it is for

Integrating with several portals has a problem that shows up late: you send an object that looks complete to you, it gets published, and only then do you see that the listing came out without a price, without a pool or with the wrong type — because each portal asks for different things and stays quiet about what it does not understand.

This endpoint lets you see that before publishing, without creating anything and without needing the portal accounts connected.

Resource URL

https://property-api.mapaprop.com/property-v1/properties/verify

Authentication

An OAuth2 token and the property-api-verify scope are required.

POST /property-v1/properties/verify
Host: property-api.mapaprop.com
Content-Type: application/json
Authorization: Bearer {access_token}

The token is obtained like any other: POST /api/action/oauth2-v1/authorize.

The request body

{
  "canonical": { …el objeto de la propiedad… },
  "portals": ["argenprop", "zonaprop", "cabaprop"]
}

The object that goes in canonical is the usual one: The property JSON object.

If you send a portal that does not exist, the request fails with a 400 instead of ignoring it silently.

Which portals it reports back

The idea is that you do not receive problems about a portal you did not configure. If you already declared Argenprop and nothing else, Zonaprop does not show up in the response nor count in the summary.

And if you have not configured any yet, you see all of them: that is the case of someone evaluating the integration who wants to see how their object converts on each portal before deciding.

publication — the publishing configuration, inside the object

Inside canonical you can send a publication key with what each portal needs from your account and from your publishing choices. It is not a field of the property: it is how you publish it.

{
  "publication": {
    "api": {
      "argenprop": { "advertiserId": 99999, "visible": true },
      "zonaprop": {
        "plan": { "plan": "SUPERDESTACADO" },
        "branch": { "custId": 1, "email": "contacto@ejemplo.com", "name": "Inmobiliaria", "phone1": "1144445555" }
      },
      "cabaprop": { "branchOfficeId": 42 }
    }
  }
}

Each portal also accepts a token (string), which is validated for shape and never for validity: this endpoint does not verify accounts. Its value does not appear anywhere in the response.

publication does not travel to the portals as one more field: it is consumed here and discarded.

The full reference —the two levels, what happens if you send something that does not belong, and the detail about the token— is on its own page: The publication key.

The response

{
  "mode": "client",
  "object": {
    "valid": true,
    "contract": [],
    "mapapropZone": "1-2-189-973",
    "conflicts": [],
    "conflicts": []
  },
  "portals": {
    "argenprop": {
      "status": "fields_complete",
      "connection": "not_verified",
      "zone": {
        "sent": {
          "code": "1-2-189-973",
          "level": 3
        },
        "publishingTo": "Mar del Plata",
        "status": "mapped"
      },
      "blockers": [],
      "pendingAtPublishTime": []
    },
    "zonaprop": {
      "status": "fields_complete",
      "connection": "not_verified",
      "zone": {
        "sent": {
          "code": "1-2-189-973",
          "level": 3
        },
        "publishingTo": "General Pueyrredón",
        "status": "mapped"
      },
      "blockers": [],
      "pendingAtPublishTime": []
    },
    "cabaprop": {
      "status": "fields_complete",
      "connection": "not_verified",
      "zone": {
        "sent": {
          "code": "1-2-189-973",
          "level": 3
        },
        "status": "not_mapped",
        "message": "Todavía no tenemos mapeada esta zona para cabaprop. Escribinos con el código de zona y la publicamos: el mapeo queda hecho para siempre."
      },
      "blockers": [],
      "pendingAtPublishTime": []
    },
    "mercadolibre": {
      "status": "coming_soon",
      "message": "MercadoLibre: disponible pronto. La integración todavía no está habilitada en este endpoint."
    }
  },
  "summary": {
    "complete": 3,
    "of": 4
  }
}

object — what happened to your object

conflicts deserves attention: if you send "type": 23 and your attributes says "Departamento", it is published as Departamento. It is not an error, it is the rule — but if that was not what you wanted, you see it here instead of in the listing.

portals — what each portal says

status values:

Each blocker carries:

{ "field": "price",
  "kind": "missing",
  "message": "`price` es obligatorio en el objeto de Mapaprop y no vino…",
  "youCanFixIt": true }

youCanFixIt answers the only question that matters about a blocker: do I fix this by sending more data, or is it a limitation of the portal? If it is true, send the data. If it is false, that portal does not admit what you are asking of it and no JSON will solve it.

zone — which zone we are going to publish in

Every portal has its own zone map, and we maintain the translation between your Mapaprop zone and that portal's. zone shows you both ends:

{ "sent": { "code": "1-2-189-973", "level": 3 },
  "publishingTo": "Mar del Plata",
  "status": "mapped" }

The states:

summary

{ "summary": { "complete": 3, "of": 4 } }

How many portals have their required fields complete, out of the total evaluated.

Mapaprop's required fields override the portal's

This is the most important thing to understand about the endpoint.

Mapaprop has its own contract of required fields, and it does not depend on what each portal asks for. If one of those fields is missing, no portal stays in fields_complete — even if that particular portal does not require it.

Example: Argenprop does not require the price to build its listing. Even so, if you do not send price:

{
  "object": {
    "valid": false,
    "contract": [ { "field": "price", "rule": "required", "detail": "" } ]
  },
  "portals": {
    "argenprop": {
      "status": "missing_data",
      "blockers": [
        { "field": "price",
          "kind": "missing",
          "message": "`price` es obligatorio en el objeto de Mapaprop y no vino. Sin él no se publica en ningún portal, lo exija o no este portal en particular.",
          "youCanFixIt": true }
      ]
    }
  },
  "summary": { "complete": 0, "of": 4 }
}

The full list of required fields is in The property JSON object.

You do not need the portal connected

The connection field tells you whether that portal's account is connected, but it does not condition anything: the object is mapped the same way and the blockers are computed the same way.

It is a piece of data on the side, and it still matters: a flawless object is not published if the account is not connected. But to perfect your object you do not need any.

Errors

{ "error": "Portales desconocidos: idealista. Válidos: argenprop, zonaprop, cabaprop, mercadolibre, mapaprop" }

MercadoLibre

It always comes out as coming_soon. The integration exists but is not enabled on this endpoint yet, and we prefer not to show you an unverified mapping: you would take it for good.

How to use it

1. Send your object exactly as you have it today.
2. Look at object.valid and object.contract first. If a required field is missing, fix that — it is blocking every portal at once.
3. Look at object.conflicts. If something shows up, your attributes and your individual fields are contradicting each other, and attributes wins.
4. Portal by portal, resolve the blockers with youCanFixIt: true.
5. The youCanFixIt: false ones you cannot resolve: they are limits of the portal.
6. Repeat. Nothing is created, so try as many times as you need.