A chave publication
O objeto do imóvel descreve o imóvel. publication descreve como você o publica: qual conta
você usa em cada portal e o que escolheu para esse anúncio.
São duas coisas diferentes e por isso estão separadas. Os metros quadrados de um apartamento são os mesmos onde quer que você publique; o plano que você contratou no Zonaprop, não.
Está em beta. É por esta chave que as capacidades de publicação são habilitadas, portanto ela vai crescer: portais novos, campos novos, canais novos. O que já está documentado aqui não muda de significado sem aviso.
Onde vai
Dentro do objeto do imóvel, como mais uma chave:
{
"code": "DEV-V3-909181",
"title": "…",
"attributes": [ … ],
"publication": { "api": { … } }
}
Viaja da mesma forma no cadastro e na verificação — é o mesmo objeto nos dois casos.
A 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>"
}
}
}
}
Os dois níveis
publication
└── api ← publicação pela API do portal
└── <portal>
O nível api não é decorativo: um portal pode ser publicado por mais de um canal. O Zonaprop,
por exemplo, aceita publicação por API e por feed XML, e cada canal tem o seu próprio contrato.
Separá-lo desde o início permite somar o outro canal sem mudar a forma do que já funciona.
Hoje apenas api está habilitado. Qualquer outra chave nesse nível é rejeitada: não é "ainda não
suportado", é desconhecido.
O que cada portal aceita
| Portal | Campo | Tipo | O que é |
|---|---|---|---|
argenprop | advertiserId | number | O seu id de anunciante no Argenprop |
visible | boolean | Se o anúncio é publicado visível | |
zonaprop | plan | object | O plano de publicação, por exemplo {"plan": "SUPERDESTACADO"} |
branch | object | Os dados de contato da filial: {custId, email, name, phone1}. Já não é necessário — veja abaixo | |
cabaprop | branchOfficeId | number | A filial (corretor registrado) no Cabaprop |
mercadolibre | listingTypeId | string | O tipo de publicação |
condition | string | A condição do imóvel | |
sellerContact | object | Os dados de contato do vendedor. Já não é necessário — veja abaixo |
Todos aceitam também um token (string), que é o da sua conta nesse portal.
Já não é necessário enviar branch e sellerContact. São os dados de contato do seu cliente
escritos no vocabulário de cada portal, e agora nós os preenchemos sozinhos a partir de
a ficha do seu cliente, que você declara uma vez e não viaja em
cada imóvel.
Se você os enviar de todo modo, os seus prevalecem: o preenchimento automático tem a precedência mais baixa de todas.
O formato deles, se você quiser enviá-los:
{
"zonaprop": { "branch": { "custId": 1, "name": "…", "phone1": "…", "email": "…" } },
"mercadolibre": { "sellerContact": { "phone": "…", "email": "…" } }
}
advertiserId e branchOfficeId continuam sendo necessários: não são dados do seu cliente, e sim
ids dentro do portal — o seu anunciante no Argenprop, o seu corretor registrado no Cabaprop — e apenas
a sua conta lá os conhece.
Não é preciso enviar todos os portais. Envie os que você vai usar; o que não estiver simplesmente não é configurado.
Sobre o token
O token é validado na forma e nunca na validade. Nós o aceitarmos não significa que ele
esteja correto nem que a sua conta exista: apenas que é uma string não vazia. Este endpoint
verifica imóveis, não contas.
E do outro lado: o valor do seu token não aparece em nenhuma resposta. Se houver um problema com
ele, dizemos qual é a chave (publication.api.zonaprop.token) e nunca o que ela contém. Também não
é armazenado junto com o objeto nem reenviado para nenhum lugar que não precise dele.
O que acontece se você enviar algo que não corresponde
A forma é validada, e o que não cumpre aparece de duas maneiras ao mesmo tempo na resposta do verify:
- Em
object.contract, com o caminho completo, a regra e um exemplo de como resolver. - Como blocker do portal afetado, que passa a
missing_data.
| Caso | O que reporta | O exemplo que te dá |
|---|---|---|
| Tipo errado | se espera number | "publication": { "api": { "argenprop": { "advertiserId": 99999 } } } |
| Portal que não existe | portal desconocido. Válidos: … | um dos válidos |
| Campo que esse portal não aceita | no es un dato de cuenta/publicación reconocido… | a lista dos que ele aceita |
Um nível diferente de api | sólo admite api | "publication": { "api": { … } } |
token vazio | 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 } } }" }
Um publication quebrado bloqueia a publicação nesse portal, mesmo que o objeto do imóvel
esteja impecável. E bloqueia apenas o portal que ele nomeia: se o problema é de
publication.api.argenprop, Zonaprop e Cabaprop seguem o seu curso. Os problemas de nível
superior —o publication inteiro, ou um nível diferente de api— afetam todos.
É de propósito: um advertiserId com o tipo errado não é um imóvel incompleto, é uma instrução
de publicação quebrada — e publicar com ela é o dano.
Nada é limpo em silêncio nem adivinhamos o que você quis dizer. Se não cumpre, nós dizemos, e dizemos como resolver.
Declarar um portal é pedir que ele seja reportado
A resposta do verify traz apenas os portais que você
declarou aqui. Se você configurou o Argenprop e mais nada, o Zonaprop não aparece — nem com
problemas, nem no summary.
Se você não enviar publication, vê todos: é o caso de quem está avaliando a integração.
publication não é um campo do imóvel
Não é armazenado junto com o imóvel e não viaja aos portais como um dado do anúncio. É consumido para configurar a publicação e depois descartado.
Por isso também você não vai vê-lo no imóvel que devolvemos: ele não faz parte dele.
Veja também
- O objeto JSON do imóvel — o objeto onde ele vive
- POST /properties/verify — teste o seu objeto, com o
seu
publication, sem criar nada
Precisa de ajuda? Entre em contato com o Suporte técnico da Mapaprop