BETA

The `publication` key

The property object describes the real estate. publication describes how you publish it: which account you use on each portal and what you chose for that listing.

They are two different things and that is why they are separate. The square meters of an apartment are the same wherever you publish; the plan you contracted on Zonaprop is not.

It is in beta. This key is where publishing capabilities get enabled, so it will grow: new portals, new fields, new channels. What is already documented here does not change meaning without notice.

Where it goes

Inside the property object, as one more key:

{
  "code": "DEV-V3-909181",
  "title": "…",
  "attributes": [ … ],
  "publication": { "api": { … } }
}

It travels the same way on creation and on verification — it is the same object in both cases.

The shape

{
  "publication": {
    "api": {
      "argenprop": {
        "advertiserId": 99999,
        "visible": true,
        "token": "<tu-token-de-argenprop>"
      },
      "zonaprop": {
        "plan": {
          "plan": "SUPERDESTACADO"
        },
        "token": "<tu-token-de-zonaprop>"
      },
      "cabaprop": {
        "branchOfficeId": 42,
        "token": "<tu-token-de-cabaprop>"
      },
      "mercadolibre": {
        "listingTypeId": "gold_special",
        "condition": "used",
        "token": "<tu-token-de-mercadolibre>"
      }
    }
  }
}

The two levels

publication
└── api            ← publishing through the portal's API
    └── <portal>

The api level is not decorative: a portal can be published through more than one channel. Zonaprop, for example, supports publishing through an API and through an XML feed, and each channel has its own contract. Separating it from the start allows adding the other channel without changing the shape of what already works.

Today only api is enabled. Any other key at that level is rejected: it is not "not supported yet", it is unknown.

What each portal accepts

Portal	Field	Type	What it is
`argenprop`	`advertiserId`	number	Your advertiser id on Argenprop
	`visible`	boolean	Whether the listing is published visible
`zonaprop`	`plan`	object	The publishing plan, for example `{"plan": "SUPERDESTACADO"}`
	`branch`	object	The branch's contact details: `{custId, email, name, phone1}`. No longer needed — see below
`cabaprop`	`branchOfficeId`	number	The branch (licensed agent) on Cabaprop
`mercadolibre`	`listingTypeId`	string	The listing type
	`condition`	string	The property's condition
	`sellerContact`	object	The seller's contact details. No longer needed — see below

All of them also accept a token (string), which is the one for your account on that portal.

You no longer need to send branch and sellerContact. They are your client's contact details written in each portal's vocabulary, and we now fill them in ourselves from your client's record, which you declare once and does not travel on every property.

If you send them anyway, yours win: the auto-fill has the lowest precedence of all.

Their shape, if you do want to send them:

{
  "zonaprop": { "branch": { "custId": 1, "name": "…", "phone1": "…", "email": "…" } },
  "mercadolibre": { "sellerContact": { "phone": "…", "email": "…" } }
}

advertiserId and branchOfficeId are still needed: they are not your client's details but ids inside the portal — your advertiser on Argenprop, your registered agent on Cabaprop — and only your account there knows them.

You do not need to send every portal. Send the ones you are going to use; what is not there simply is not configured.

About the `token`

The token is validated for shape and never for validity. Us accepting it does not mean it is correct or that your account exists: only that it is a non-empty string. This endpoint verifies properties, not accounts.

And on the other side: your token's value does not appear in any response. If there is a problem with it, we tell you which key it is (publication.api.zonaprop.token) and never what it contains. It is not stored with the object either, nor forwarded anywhere that does not need it.

What happens if you send something that does not belong

The shape is validated, and whatever does not comply shows up in two ways at once in the verify response:

In object.contract, with the full path, the rule and an example of how to fix it.
As a blocker on the affected portal, which turns to missing_data.

Case	What it reports	The example it gives you
Wrong type	`se espera number`	`"publication": { "api": { "argenprop": { "advertiserId": 99999 } } }`
Portal that does not exist	`portal desconocido. Válidos: …`	one of the valid ones
Field that portal does not accept	`no es un dato de cuenta/publicación reconocido…`	the list of the ones it does accept
A level other than `api`	`sólo admite api`	`"publication": { "api": { … } }`
Empty `token`	`se espera un string no vacío`	`"token": "<tu-token-de-argenprop>"`

{ "field": "publication.api.argenprop.advertiserId",
  "rule": "type",
  "value": "noventa",
  "detail": "se espera number",
  "fix": "\"publication\": { \"api\": { \"argenprop\": { \"advertiserId\": 99999 } } }" }

A broken publication blocks publishing on that portal, even if the property object is flawless. And it blocks only the portal it names: if the problem is in publication.api.argenprop, Zonaprop and Cabaprop carry on. Top-level problems —the whole publication, or a level other than api— affect all of them.

It is on purpose: a mistyped advertiserId is not an incomplete property, it is a broken publishing instruction — and publishing with it is the damage.

Nothing is cleaned up silently and we do not guess what you meant. If it does not comply, we tell you, and we tell you how to fix it.

Declaring a portal is asking us to report it

The verify response brings only the portals you declared here. If you configured Argenprop and nothing else, Zonaprop does not show up — neither with problems nor in the summary.

If you do not send publication, you see all of them: that is the case of someone evaluating the integration.

`publication` is not a field of the property

It is not stored with the real estate and it does not travel to the portals as listing data. It is consumed to configure the publishing and then discarded.

That is also why you will not see it in the property we return to you: it is not part of it.

The publication key

The `publication` key