Política de compatibilidade
A API não tem versionamento por URL. Em vez disso, seguimos três regras para que integrações já em produção não parem de funcionar sem aviso:
- Comportamento novo ganha URL nova. Quando o formato dos dados muda, o endpoint antigo continua respondendo exatamente como antes e a mudança sai em outro caminho.
- Campos podem ser acrescentados a qualquer momento. Trate a resposta como um objeto aberto: ignore o que não conhece em vez de quebrar.
- Endpoints descontinuados continuam no ar. Eles saem da referência, mas seguem respondendo — a lista abaixo mostra o substituto de cada um.
Dúvidas sobre alguma mudança ou precisa de prazo para migrar? Escreva para contaovosdengue@gmail.com.
Endpoints descontinuados
Todos continuam funcionando e devolvendo exatamente o mesmo conteúdo de antes. Só não recebem campos novos.
| Endpoint | Use no lugar | Motivo |
|---|
/api/getmunicipalityblockspublic | /api/getmunicipalityblocksvisitpublic | O nome dizia quarteirões, mas o retorno sempre foi o das visitas realizadas neles. |
/api/getmunicipalityedlvisitspublic | /api/getmunicipalityedlmaintenancepublic | EDLs recebem manutenções, não visitas; os campos passaram de edl_visit_* para edl_maintenance_*. |
Histórico de mudanças
2026-08-01
Nomes corretos para quarteirões e manutenções de EDLs
NovidadeDescontinuação
- Novo
/api/getmunicipalityblocksvisitpublic — as visitas realizadas em quarteirões, com um registro por visita. Mesmo conteúdo do antigo /api/getmunicipalityblockspublic, agora com o nome certo. - Novo
/api/getmunicipalityblockspublic-2 — os quarteirões em si, um registro por quarteirão, com polígono, totais de imóveis por tipo e média de ações. - Novo
/api/getmunicipalityedlmaintenancepublic — as manutenções de EDLs, com os campos renomeados de edl_visit_* para edl_maintenance_*. - Descontinuados
/api/getmunicipalityblockspublic e /api/getmunicipalityedlvisitspublic — seguem no ar, com o mesmo retorno de sempre.
Nenhuma integração existente precisa mudar. A migração é recomendada apenas para quem quer os nomes de campo corretos ou os dados dos quarteirões separados das visitas.
2026-07-30
Ovitrampa rural e correção da semana epidemiológica
Novidade
/api/postcounting passou a aceitar ovitrap_type_id na instalação de uma ovitrampa: 1 para urbana (padrão, quando o campo não é enviado) e 2 para rural. Qualquer outro valor devolve 400 "Tipo de ovitrampa inválido".- A validação de semana epidemiológica de
/api/postcounting e /api/postaction passou a comparar ano e semana em conjunto. Antes, uma data de um ano futuro com número de semana baixo podia ser aceita indevidamente.
2026-07-28
Novos endpoints públicos de EDLs, ovitrampas e pontos estratégicos
Novidade
/api/getmunicipalityedlspublic — EDLs cadastrados por município./api/getmunicipalityovitrapspublic — ovitrampas cadastradas, com coordenadas e média de ovos./api/getmunicipalityplacespublic — pontos estratégicos, com tipo, subtipo e área.- Todos aceitam
country, state, municipality e page, como os demais endpoints públicos.
2026-04-23
Envio de visitas em quarteirões
Novidade
- Novo
/api/postaction — registra uma visita com os imóveis trabalhados e os depósitos encontrados por classe (a1, a2, b, c, d1, d2, e). - Enviando
block_group_id em vez de block_id, o quarteirão é criado automaticamente dentro do município da chave. - Respostas específicas:
403 quando o quarteirão é de outro município e 409 quando já existe visita para aquele quarteirão, ano e semana.
2026-03-27
A chave passou a ser lida da URL
Mudança de comportamento
Em todos os endpoints privados, a key passou a ser lida exclusivamente da query string (?key=SUA_CHAVE), inclusive nos POST. Integrações que enviavam a chave apenas no corpo do formulário começam a receber 404 "Wrong key" — basta mover a chave para a URL, mantendo os demais campos no corpo.
2026-02-24
Remoção de visitas e quarteirões
Novidade
/api/postdeleteaction — remove a visita de um quarteirão, identificada por block_group_id e date./api/postdeleteblock — remove o quarteirão.
2026-02-04
Filtro por período nas contagens privadas
Novidade
/api/lastcounting passou a aceitar date_start e date_end, permitindo recortar as contagens por intervalo de datas em vez de percorrer todas as páginas.
2025-10-19
Sincronização incremental nas contagens públicas
Novidade
/api/lastcountingpublic passou a aceitar id (apenas ocorrências a partir daquele identificador), date (data de inclusão) e date_collect (data de coleta). São esses filtros que permitem manter uma base espelhada sem rebaixar todo o histórico.
2025-03-18
Filtro por período nas contagens públicas
Novidade
/api/lastcountingpublic passou a aceitar date_start e date_end.
2025-03-06
Remoção de ovitrampas
Novidade
/api/postdeleteovitrap — remove uma ovitrampa a partir do ovitrap_group_id, dentro do município da chave.