La clave publication

El objeto propiedad describe el inmueble. publication describe cómo lo publicás: qué cuenta usás en cada portal y qué elegiste para ese aviso.

Son dos cosas distintas y por eso están separadas. Los metros cuadrados de un departamento son los mismos publiques donde publiques; el plan que contrataste en Zonaprop, no.

Dónde va

Adentro del objeto propiedad, como una clave más:

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

Viaja igual en el alta y en la verificación — es el mismo objeto en los dos casos.

La forma

{
  "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>"
      }
    }
  }
}

Los dos niveles

publication
└── api            ← publicación por la API del portal
    └── <portal>

El nivel api no es decorativo: un portal puede publicarse por más de un canal. Zonaprop, por ejemplo, admite publicación por API y por feed XML, y cada canal tiene su propio contrato. Separarlo desde el principio permite sumar el otro canal sin cambiarle la forma a lo que ya funciona.

Hoy sólo api está habilitado. Cualquier otra clave a ese nivel se rechaza: no es "todavía no soportado", es desconocido.

Qué acepta cada portal

Todos aceptan además un token (string), que es el de tu cuenta en ese portal.

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

advertiserId y branchOfficeId sí siguen haciendo falta: no son datos de tu cliente sino ids dentro del portal —tu anunciante en Argenprop, tu matriculado en Cabaprop— y sólo los sabe tu cuenta ahí.

No hace falta que mandes todos los portales. Mandá los que vayas a usar; lo que no está, simplemente no se configura.

Sobre el token

Y del otro lado: el valor de tu token no aparece en ninguna respuesta. Si hay un problema con él, te decimos cuál es la clave (publication.api.zonaprop.token) y nunca qué contiene. Tampoco se guarda con el objeto ni se reenvía a ningún lado que no lo necesite.

Qué pasa si mandás algo que no corresponde

La forma se valida, y lo que no cumple aparece de dos maneras a la vez en la respuesta del verify:

1. En object.contract, con la ruta completa, la regla y un ejemplo de cómo se arregla.
2. Como blocker del portal afectado, que pasa a missing_data.

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

No se limpia en silencio ni se adivina qué quisiste decir. Si no cumple, te lo decimos y te decimos cómo arreglarlo.

Declarar un portal es pedir que te lo reporten

La respuesta del verify trae sólo los portales que declaraste acá. Si configuraste Argenprop y nada más, Zonaprop no aparece — ni con problemas, ni en el summary.

Si no mandás publication, los ves todos: es el caso de quien está evaluando la integración.

publication no es un campo de la propiedad

No se guarda con el inmueble y no viaja a los portales como un dato del aviso. Se consume para configurar la publicación y se descarta.

Por eso tampoco lo vas a ver en la propiedad que te devolvemos: no forma parte de ella.

Ver también

• El objeto JSON de la propiedad — el objeto donde vive
• POST /properties/verify — probá tu objeto, con su publication, sin crear nada