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.
Está en beta. Esta clave es por donde se habilitan las capacidades de publicación, así que va a crecer: portales nuevos, campos nuevos, canales nuevos. Lo que ya está documentado acá no cambia de significado sin aviso.
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"
},
"branch": {
"custId": 1,
"email": "contacto@ejemplo-inmobiliaria.com",
"name": "Inmobiliaria de ejemplo",
"phone1": "1144445555"
},
"token": "<tu-token-de-zonaprop>"
},
"cabaprop": {
"branchOfficeId": 42,
"token": "<tu-token-de-cabaprop>"
},
"mercadolibre": {
"listingTypeId": "gold_special",
"condition": "used",
"sellerContact": {
"email": "contacto@ejemplo-inmobiliaria.com",
"phone": "1144445555"
},
"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
| Portal | Campo | Tipo | Qué es |
|---|---|---|---|
argenprop | advertiserId | number | Tu id de anunciante en Argenprop |
visible | boolean | Si el aviso se publica visible | |
zonaprop | plan | object | El plan de publicación, por ejemplo {"plan": "SUPERDESTACADO"} |
branch | object | Los datos de contacto de la sucursal: {custId, email, name, phone1} | |
cabaprop | branchOfficeId | number | La sucursal (matriculado) en Cabaprop |
mercadolibre | listingTypeId | string | El tipo de publicación |
condition | string | La condición del inmueble | |
sellerContact | object | Los datos de contacto del vendedor |
Todos aceptan además un token (string), que es el de tu cuenta en ese portal.
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
El token se valida de forma y nunca de validez. Que lo aceptemos no significa que sea
correcto ni que tu cuenta exista: sólo que es un string no vacío. Este endpoint verifica
propiedades, no cuentas.
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:
- En
object.contract, con la ruta completa, la regla y un ejemplo de cómo se arregla. - Como blocker del portal afectado, que pasa a
missing_data.
| Caso | Qué reporta | Ejemplo que te da |
|---|---|---|
| Tipo equivocado | se espera number | "publication": { "api": { "argenprop": { "advertiserId": 99999 } } } |
| Portal que no existe | portal desconocido. Válidos: … | uno de los válidos |
| Campo que ese portal no acepta | no es un dato de cuenta/publicación reconocido… | la lista de los que sí acepta |
Nivel distinto de api | sólo admite api | "publication": { "api": { … } } |
token vacío | 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 } } }" }
Un publication roto bloquea la publicación en ese portal, aunque el objeto de la propiedad
esté impecable. Y bloquea sólo al portal que nombra: si el problema es de
publication.api.argenprop, Zonaprop y Cabaprop siguen su curso. Los problemas de nivel superior
—publication entero, o un nivel distinto de api— afectan a todos.
Es a propósito: un advertiserId mal tipado no es una propiedad incompleta, es una instrucción
de publicación rota — y publicar con ella es el daño.
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
¿Necesitás ayuda? Contactá al Soporte técnico de Mapaprop