Conceitos-chave
As regras que valem em toda a API: catálogo por nome, características, valores, moderação, limites e erros.
Leia antes de integrarEstas são as regras que valem em toda a API pública. Entendendo elas, os endpoints de imóveis, pessoas, leads e atendimento ficam previsíveis, e a maior parte dos erros deixa de acontecer.
🗂️ Tudo por nome, não por id
Cada convênio tem o seu próprio catálogo. Tipos de imóvel, características, bairros, cidades, tipos de contato, tipos de relação, motivos (de descarte, de cancelamento de visita, de parecer) e tipos de atividade variam de uma imobiliária para outra. Por isso, na API pública você envia tudo pelo nome cadastrado, nunca por um id interno.
Antes de escrever, consulte o catálogo do convênio:
| Consulte | Para obter |
|---|---|
GET /schema/property-types | os tipos de imóvel disponíveis |
GET /schema/properties?propertyType=<nome> | os campos e as características de um tipo |
GET /schema/lookups | cidades, locais de chave, tipos de contato e relação |
GET /schema/neighborhoods?city=<nome> | o bairro certo dentro da cidade |
GET /schema/support | as listas de apoio do convênio: motivos, tipos de atividade, mídias, equipes, profissões, índices de reajuste e demais tabelas auxiliares, todas por nome |
GET /schema/holidays | os feriados do ano; filtre por state e city para incluir os estaduais e municipais |
Nome desconhecido ou ambíguoUm nome que não existe no convênio volta
422 UNKNOWN_NAME. Um nome que casa com mais de um cadastro volta422 AMBIGUOUS_NAME(a mensagem traz os ids para você desambiguar). A API não cria cadastros auxiliares sozinha: consulte o schema e envie o nome exato. As exceções são explícitas e têm escopo próprio: incluir cidade e bairro (localizacao:write) e mídia (midias:write).
🏷️ Características do imóvel
Característica também é cadastro do convênio, então varia de um para outro. Consulte GET /schema/properties?propertyType=<nome> para saber quais existem e de que tipo. A leitura devolve sempre uma lista, e essa é a forma recomendada também na escrita, porque deixa explícito o nome e o valor de cada item:
{
"characteristics": [
{ "name": "Quartos", "value": 3 },
{ "name": "Aquec. elétrico", "value": true }
]
}{
"characteristics": {
"Quartos": 3,
"Alarme": true
}
}
Não repita uma característicaO mesmo nome duas vezes volta
422comDUPLICATE_CHARACTERISTIC.
🔢 Valores numéricos
Características de tipo number são inteiras: 3 sim, 3.5 não (casa decimal em campo inteiro volta 422 com INVALID_CHARACTERISTIC_VALUE). Para valor fracionário existem os tipos decimal, currency e percent; o catálogo diz qual é qual.
Número aceita os dois formatos, sem adivinhação:
| Você envia | A API entende |
|---|---|
"1.250,50" | 1250,5 (pt-BR) |
"1250,50" | 1250,5 |
"1,250.50" | 1250,5 (en) |
"1250.50" | 1250,5 |
"1.250" | 1250 (um separador com três casas = milhar) |
🛡️ Moderação e duplicidade
Imóvel nasce em moderaçãoTodo imóvel criado por
POST /propertiesnasce emem_moderacaoe só entra em feed de portal quando alguém do convênio o libera no produto. Por isso,vago_disponivelnão é aceito emPATCH /properties/{id}/status. Detalhes em Ambiente e moderação.
Reenvios são seguros e a duplicidade é tratada para você:
| Cenário | O que acontece |
|---|---|
Reenviar um lead com o mesmo external_id | 200 com deduped: true, sem criar um segundo lead |
| Repetir o endereço de um imóvel | 409 DUPLICATE_ADDRESS com a lista duplicates; altere o existente em vez de criar outro |
🧭 Ação nomeada, nunca edição livre
No fluxo comercial (atendimento, visita, proposta, atividade), a API não tem "edição livre" do registro: ela oferece ações nomeadas, uma por rota (annotations, discard, visitas, status, feedback, propostas, complete, cancel). Quando a ação não pode ser feita, a resposta traz um código estável:
| Trava | Código |
|---|---|
O atendimento tem pendência que impede a ação (a message diz qual) | 422 CHECKLIST_PHASE_PENDING |
| Horário de visita que já passou | 422 VISIT_SLOT_IN_PAST |
| Horário indisponível para o corretor | 409 VISIT_SLOT_TAKEN |
| Chave do imóvel indisponível no horário | 409 VISIT_KEY_UNAVAILABLE |
| Módulo não contratado pelo convênio | 403 MODULE_NOT_ENABLED |
Não existe parâmetro para pular regra. E a API não exclui cadastro: registro sai de uso mudando a situação (descartar, cancelar, inativar). O que se desfaz é só vínculo: tirar etiqueta, desvincular proprietário, remover foto.
🔒 Dado pessoal tem uma porta só
Registros e imóveis trazem a pessoa pelo id (e, no máximo, o nome). Documento, telefone, e-mail e endereço saem só por GET /people/{id}, com pessoas:read. Proprietário do imóvel e locador do contrato saem só como personId.
📡 Webhooks
Toda escrita pela API dispara o webhook do evento (imóvel incluído, visita agendada, anotação no atendimento...), com o autor api_key, do mesmo jeito que as alterações feitas pela imobiliária. O cadastro dos endpoints é feito no sistema, em Configurações.
⏱️ Limites de requisição
Dois tetos por chave: 120 requisições por minuto e 1.000 por hora (ajustáveis por chave). Ao estourar, a resposta é 429 com o cabeçalho Retry-After.
Um 429 nunca descarta em silêncioSe você recebeu
429, a requisição não foi processada. Aguarde o prazo doRetry-Aftere reenvie: nada foi perdido.
⚠️ Erros
Toda resposta de erro tem a mesma forma em toda a /pub/v1, com um code estável entre versões para você decidir por código sem parsear a mensagem em português:
{
"statusCode": 422,
"code": "UNKNOWN_NAME",
"error": "Unprocessable Entity",
"message": "..."
}O 409 acrescenta duplicates; um 5xx nunca carrega detalhe interno. A tabela completa de status e códigos está em Erros e códigos.
➡️ Próximos passos
Updated 20 days ago
