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-09-11
Datas e coordenadas impossíveis passam a ser recusadas
Mudança de comportamento
- Toda data de registro (instalação e coleta da leitura, visita, manutenção e instalação de EDL) precisa estar entre 01/01/1900 e hoje. Antes, a data de coleta só tinha o formato conferido, e um ano digitado com três dígitos, como
0202-08-14, era gravado. Carga retroativa de qualquer ano a partir de 1900 continua aceita. - Latitude ou longitude exatamente zero passam a ser recusadas em todos os endpoints: é posição que não foi registrada, não um lugar.
- A resposta é
400 com a frase dizendo qual campo e por quê, por exemplo "Data de coleta: 0202-08-14 é anterior a 01/01/1900 — confira o ano."
Quem já manda datas e coordenadas reais não precisa mudar nada. Um envio que antes era aceito com data impossível ou coordenada zerada passa a receber 400 em vez de 200.
2026-09-11
Edição de registros, chave no cabeçalho e correções
Novidade
- Novos
/api/posteditovitrap, /api/posteditcounting, /api/posteditblock, /api/posteditaction, /api/posteditedl, /api/posteditedlmaintenance e /api/posteditplace — editam registros existentes, com edição parcial, troca de código ou data e cópia opcional do endereço novo para as leituras antigas (atualizar_desde). - A chave pode ir no cabeçalho
Authorization: Bearer SUA_CHAVE, em todos os endpoints. O ?key= continua aceito. /api/postdeleteaction respondia erro 500 em toda chamada que achava o quarteirão; agora apaga a visita, inclusive as criadas pela própria API./api/postcounting: quando a coordenada da ovitrampa muda, os campos de endereço que não vieram no pedido passam a ser mantidos. Antes eram apagados.- Apagar uma leitura, visita ou manutenção pela API passou a recalcular a média do registro (ovos da ovitrampa, visitas do quarteirão, água da EDL).
Nenhuma integração existente precisa mudar. A única diferença visível para quem já integrou é a do /api/postcounting: um endereço que antes era apagado agora é mantido.
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.