Pular para o conteúdo
ZapCar
Developersv1

Changelog

Mudanças na API e na documentação, com o que exige ajuste de quem já integra.

18/10/2026 · ambiente de teste

  • Sandbox, Atenção: o bloco veiculo só vem onde a produção o devolve. Com chave zc_test_, a consulta concluída de debitos, debitos-estadual, historico-proprietarios, decodificacao-chassi, decodificacao-motor, score-credito, crlv, atpve e codigo-seguranca deixa de trazer veiculo, proprietario e ultimo_licenciamento fictícios: vem o envelope e o dados reduzido, marcado com _sandbox (null nos três de documento, como em produção). Em gravame e renajud o veiculo continua, mas proprietario e ultimo_licenciamento também saem. Em produção nada muda: esses blocos nunca existiram nesses serviços. Se o seu teste automatizado lia veiculo num deles, ele estava testando um contrato que a produção não entrega: leia o dados de uma consulta real.

18/10/2026 · documentação

  • Nova documentação: ZapCar Developers. A página única virou um portal com rotas próprias (introdução, quickstart, referência por endpoint, serviços, guias, erros, webhooks), busca com Ctrl/Cmd + K, API Explorer no sandbox e simulador de webhooks. Os links antigos com âncora (/api-integradores/docs#criar, #sandbox…) levam à página nova. Nenhuma mudança de comportamento na API.
  • Correções de texto, conferidas no backend: o replay de uma Idempotency-Key no POST /v1/consultas devolve 201 com a resposta original (o 200 é só a solicitação idêntica reaproveitada); X-ZapCar-Delivery identifica a entrega e se repete nas reentregas dela; vehicle.document.changed dispara quando o monitoramento detecta comunicação de venda; a rotação de chave exige revogar a atual antes de gerar a nova (uma chave ativa por ambiente); no score-credito e no situacao-cpf a finalidade é registrada quando enviada, sem recusar o pedido.
  • Catálogo de erros: 400 FINALIDADE_OBRIGATORIA entrou na lista de reserva da documentação (já existia na API). Os códigos de falha do processamento (erro_codigo) passam a ser listados por inteiro.

Últimas mudanças na API. A maioria é aditiva; o item marcado Atenção pode exigir ajuste de quem já integra.

15/10/2026

  • Novos serviços: consultas de pessoa física e jurídica. Cadastro Simples e Completo (CPF e CNPJ), Crédito Único e Biro (CPF e CNPJ), CNH Nacional, Débitos Trabalhistas (CNDT) e Dívida Ativa da União, todos com o mesmo formato de dados (ver “Consultas de pessoa”). Exigem finalidade e declaracao_finalidade: true; sem registro na base, o valor é estornado. Campo novo cnh no POST /v1/consultas e erro novo 400 CNH_INVALIDA. Aparecem em GET /v1/servicos quando forem liberados.

14/10/2026

  • Novo serviço: Laudo ECV Premium. Slug ecv-premium, por placa. Mesmo formato da consulta-completa (sem fotosLeilao) e mais três blocos em dados: remarketing (venda em leilão de financeira, seguradora ou frota, com a inspeção do leiloeiro por parte do veículo), anuncios (data, quilometragem, valor e opcionais de cada anúncio encontrado) e codigosFipe. As passagens por leilão do remarketing entram em leilao.ocorrencias. Só aparece em GET /v1/servicos quando estiver ativo no catálogo.
  • Atenção: Consulta Completa com nova base. O serviço consulta-completa passou a ser atendido por uma base nova, que junta a base veicular, o gravame, o histórico de quilometragem e o de roubo e furto. O formato de dados é o mesmo; o que muda é quais blocos vêm preenchidos.
  • Novos blocos em dados: historicoKm (leituras com km, data e dataIso, mais inconsistente quando uma leitura é menor que a anterior), historicoProprietarios (nome, CPF/CNPJ, ano de exercício e UF de cada registro) e rouboFurto (constaOcorrencia, ocorrenciaAtiva e o histórico, inclusive as ocorrências encerradas). O leilao volta a trazer as ocorrências e ganha score, a avaliação do leiloeiro. Em veiculo, a cadeia sai em historico_proprietarios. Os três seguem a regra de sempre: null é "não verificado", lista vazia é "sem registro".
  • Atenção: blocos que deixam de vir. renainf (infrações detalhadas), imagensOutras, alertasSinistro e informacoesAvulsas não vêm mais; fotosLeilao continua, com a URL de cada foto; restricoes.recall, situacaoLicenciamento e licenciadoAte vêm null. restricoes.restricaoRenainf continua, a partir do valor de RENAINF em aberto. Consultas antigas mantêm os dados com que foram concluídas.

09/10/2026

  • Débitos Estaduais: nova base, nas 27 UFs, só com a placa. O serviço debitos-estadual passou a ser atendido por uma base nacional. Basta placa e uf, em qualquer estado (BA, PE e SE incluídos); renavam, documento e chassi não são mais exigidos e, se enviados, são ignorados, então integrações antigas seguem funcionando. O erro DEBITOS_DADOS_OBRIGATORIOS deixa de existir. Em dados, as listas ipvas, licenciamentos, dpvats e multas continuam, agora com um item por categoria (multas por órgão e, quando houver, as infrações RENAINF com detalhe); dividaativa deixa de vir. Item com valor: null é débito confirmado sem valor informado, nunca “nada consta”. A UF do laudo passa a ser a do registro do veículo.
  • Consulta Simples: nova base estadual, agora única. O serviço consulta passou a ser atendido por uma única base estadual; a troca automática entre duas bases anunciada em 19/09 deixou de existir. Nenhum campo mudou de nome ou tipo em dados, em veiculo ou no topo da resposta, e o schema_version segue o mesmo.
  • Restrições judicial, administrativa, tributária e de guincho passam a ser verificadas. A base nova tem campo próprio para as quatro: restricaojudicial, restricaoadministrativa, restricaotributaria e restricaoguincho vêm "NADA CONSTA" ou com a ocorrência, e nao_verificado costuma vir vazio. Quando o estado não responde um item, ele continua vazio e listado em nao_verificado: nunca trate isso como “nada consta”.
  • Proprietário: nome e CPF/CNPJ continuam vindo. A base nova devolve só o nome; o documento passa a vir de uma segunda base, consultada logo depois. Quando ela não libera o dado, proprietario_s_.documento vem "" e proprietario.documento vem null, como já podia acontecer antes. Os campos e o formato não mudaram.
  • O PDF passa a ser sempre desenhado pela ZapCar. O GET /v1/consultas/:id/pdf mantém as mesmas seções; como a base nova não emite documento próprio, o arquivo é sempre o nosso layout. Itens que a base não respondeu saem como NÃO INFORMADO.
  • Decodificação de Motor: nova base. O serviço decodificacao-motor passou a ser atendido pela base nacional por número de motor. Os campos de dados continuam os mesmos e ganham renavam, situacao e categoria. Duas mudanças: tipo_possivel (sugestões da Tabela FIPE) passa a vir sempre vazio neste serviço, e marca/modelo podem vir null quando a base não os informa. Para FIPE, use decodificacao-chassi ou o serviço de FIPE.
  • Novo serviço: Informações da Comunicação de Venda. Slug comunicacao-venda, por placa. Devolve a data da venda e do registro, o comprador (nome e CPF/CNPJ completos) e o documento do vendedor, quando há comunicação de venda registrada no DETRAN. Por trazer dado pessoal de terceiro, exige finalidade e declaracao_finalidade: true: sem eles, 400 FINALIDADE_OBRIGATORIA antes de cobrar. Sem comunicação registrada, a consulta termina em erro com retryable: false e o valor é estornado. Aparece no catálogo (GET /v1/servicos) quando for liberado.

29/09/2026

  • Gravame e RENAJUD, Atenção: nova base principal, com segunda tentativa automática. As duas consultas passam a ser atendidas por uma nova base principal; se ela falhar, a mesma chamada tenta a base anterior antes de devolver erro, sem cobrança dupla para você. Placa inválida ou veículo não encontrado não passam para a segunda base. Endpoint, slugs, preço e nomes de campo não mudaram, e a leitura de restrição continua a mesma (descricaostatus / statusdoveiculo no gravame, consta_renajud no RENAJUD). O que muda: (1) os dados de identificação do veículo ficam mais enxutos: em gravame, renavam, anofabricacao, anomodelo, cor, municipio, combustivel e motor podem vir null; em renajud, os campos do veículo no topo e o chassi de cada item também. Se o seu código exige esses campos, trate o null ou use o bloco veiculo; (2) o PDF passa a ser gerado pela ZapCar no mesmo layout de laudo, e não mais o documento emitido pela base: ele só volta a ser o da base quando a segunda tentativa atende. Se você extrai texto do PDF por posição, revise. Consultas anteriores não mudam.
  • Débitos Estaduais, Atenção: o sandbox passa a validar a UF como a produção. Com chave zc_test_, debitos-estadual em UF não atendida (hoje BA, PE e SE) agora responde 400 UF_INDISPONIVEL, e UF atendida sem o campo exigido, 400 DEBITOS_DADOS_OBRIGATORIOS. Antes, o teste aceitava essas chamadas e só a produção recusava. Em produção nada muda: essas chamadas já eram recusadas sem cobrança; a mensagem de UF_INDISPONIVEL passa a listar as UFs atendidas. A lista viva é campos_por_uf em GET /v1/servicos. Se o seu teste automatizado usa uma dessas UFs, troque por uma da lista.
  • Não confundir com debitos. debitos (Débitos + Código de Barras) atende todas as UFs; debitos-estadual consulta a base de cada estado e só as UFs de campos_por_uf.

28/09/2026 · documentação

  • 2ª via do ATPV-e, Atenção: a declaração aceite_atpve agora está documentada. Desde 23/09/2026, POST /v1/consultas com servico: "atpve" exige aceite_atpve: { aceito: true, versao }, com a versão vigente de GET /public/avisos/atpve. Sem a declaração: 422 ACEITE_ATPVE_OBRIGATORIO; com versão antiga: 409 AVISO_ATPVE_DESATUALIZADO; nada é cobrado nos dois casos. Esta página ainda dizia que bastava a placa. Ver 2ª via do ATPV-e.
  • Catálogo de erros completo. A tabela de Códigos de erro passa a ser lida de GET /public/api-erros e inclui os códigos que faltavam: ACEITE_ATPVE_OBRIGATORIO, AVISO_ATPVE_DESATUALIZADO, IMAGEM_NOT_FOUND, IMAGEM_TIPO_INVALIDO, IMAGEM_INDICE_INVALIDO, SANDBOX_INDISPONIVEL e SANDBOX_SEM_DOCUMENTO.
  • Correções de texto. Idempotency-Key vale também em POST /v1/fipe/tabela; o webhook tem 10 segundos para responder; data.servico e data.status do webhook usam os nomes internos; o consumo por chave fica em Conta › Integrações, aba Consumo. Nenhuma mudança de comportamento na API.

25/09/2026

  • Novo serviço: consulta-nfe. Nota fiscal eletrônica pela chave de acesso (44 dígitos, sem placa): situação e eventos (autorização, cancelamento, carta de correção), emitente, destinatário, produtos, totais e transporte. Entrega JSON (dados) e PDF. Só aparece em GET /v1/servicos quando estiver ligado no catálogo; até lá o POST responde 422 SERVICO_INDISPONIVEL.
  • Novo serviço: situacao-cpf. Situação cadastral do CPF na Receita Federal (regular, suspensa, cancelada…), com nome, datas de nascimento e de inscrição e código de controle. Exige documento (CPF, sem placa) e data_nascimento (dd/mm/aaaa); entrega JSON (dados) e PDF. Só aparece em GET /v1/servicos quando estiver ligado no catálogo; até lá o POST responde 422 SERVICO_INDISPONIVEL.
  • Códigos de erro novos e sandbox. 400 DATA_NASCIMENTO_INVALIDA (situacao-cpf) e 400 CHAVE_NFE_INVALIDA (consulta-nfe): os dois recusam o pedido antes de cobrar. Com chave zc_test_, os dois serviços validam como a produção e devolvem dados fictício no formato real, sem o bloco veiculo.

24/09/2026

  • POST /v1/fipe agora devolve o valor do mês vigente + histórico. A placa segue identificando o veículo; o valor de cada item passou a ser o da referência FIPE atual (antes podia vir defasado), com os campos novos historico[] e fonte_valor. Aditivo: nenhum campo saiu. Ver Tabela FIPE por placa.
  • Novo: Tabela FIPE sem placa. Navegue a tabela com GET /v1/fipe/tabela/referencias, /{tipo}/marcas, …/modelos e …/anos (todos gratuitos), ou parta do código FIPE com /{tipo}/codigo/{codigo_fipe}/anos. O valor sai em POST /v1/fipe/tabela (síncrono, R$ 0,10 por requisição, serviço fipe-tabela), com historico: true para os últimos meses. Mesma política de estorno e Idempotency-Key do POST /v1/fipe. Detalhes em FIPE por marca, modelo e ano.
  • O que NÃO mudou: POST /v1/fipe (por placa) continua igual, e o codigo_fipe que ele devolve serve de entrada para o endpoint novo.

22/09/2026

  • Voltou: serviço historico-proprietarios. A cadeia de titularidade do veículo (donos anteriores: nome, CPF/CNPJ, ano de exercício, município e UF) volta a ser vendida como serviço avulso, chaveado só por placa. Fluxo idêntico aos demais: POST /v1/consultas → polling em GET /v1/consultas/:id → dados.proprietarios[] + PDF. O serviço só aparece em GET /v1/servicos quando estiver ligado no catálogo; até lá o POST responde 422 SERVICO_INDISPONIVEL.
  • O que NÃO mudou: consulta, consulta-completa, consulta-veicular e os demais continuam devolvendo apenas o proprietario atual. O campo historico_proprietarios do bloco veiculo segue ausente neles: a cadeia só existe no serviço avulso.
  • LGPD: o resultado contém dados pessoais de terceiros. Use apenas para a finalidade da consulta e não redistribua o JSON nem o PDF.

21/09/2026 · tarde

  • Chegou o ambiente de teste. Gere uma chave zc_test_ no painel e integre sem gastar saldo: mesma URL, mesmos endpoints, nenhuma base real consultada, nenhum dado pessoal verdadeiro. O desfecho é escolhido pela placa: TST0001 conclui limpo, TST0404 devolve erro definitivo, TST0503 devolve falha retentável e TST9999 nunca sai de processando (para você testar o seu timeout). Toda resposta de teste vem marcada com ambiente: "test". Detalhes em Ambiente de teste.
  • 1 chave ativa por ambiente. A chave de teste não ocupa a vaga da de produção: você mantém as duas ao mesmo tempo.
  • Esclarecimento sobre webhooks: os eventos query.* são da conta, não só da API. Consulta feita no portal pela sua equipe, ou pelo bot do Telegram, também chega ao seu endpoint. Comportamento antigo, que faltava estar escrito.

21/09/2026

  • Correção importante no exemplo de retry. O exemplo em JavaScript sugeria continuar o GET no mesmo id quando a consulta falhava com retryable: true. Isso nunca produz resultado: status: "erro" é terminal, e só um POST novo cria outra tentativa. O exemplo foi reescrito como cliente de produção: timeout por requisição, Idempotency-Key, polling com teto, tratamento de 429 com Retry-After, backoff de 2s/5s/10s e no máximo 3 tentativas. Se você copiou o exemplo antigo, vale trocar.
  • Idempotency-Key agora vale também no POST /v1/fipe (antes só no POST /v1/consultas). Como o débito da FIPE acontece antes da chamada ao provedor, um timeout de rede seguido de retry cobrava duas vezes. Opcional e retrocompatível: sem o cabeçalho, nada muda.
  • Novo campo schema_version em GET /v1/consultas/:id, começando em "1.0". Diz se a forma dos campos mudou: minor é só acréscimo; major não sai sem aviso aqui. Ver Contrato de resposta.
  • retryable em todos os erros. Faltava nos dois casos que não passavam pelo tratador da /v1: o 404 de URL inexistente e o 500 inesperado. Agora o campo está em toda resposta de erro, como o catálogo já prometia.
  • Documentação nova: Idempotência (a implementação existia e não estava documentada), erro da requisição x erro no processamento, contrato e schema_version, rate limits com os cabeçalhos RateLimit-* e Retry-After, segurança e LGPD e como testar sem gastar saldo. Exemplos em Python, e verificação de assinatura de webhook em PHP e Python.
  • OpenAPI com schemas completos. A descrição passou a declarar o corpo das respostas (ConsultaResponse, Veiculo, ApiError, WebhookPayload…), os enums, os campos obrigatórios e os erros de cada rota: o suficiente para gerar SDK tipado em TypeScript, Python, PHP, Java e C#.
  • Menu reorganizado e este changelog movido para o fim: quem chega agora começa pela visão geral, não pelo histórico.

19/09/2026

  • Consulta Simples: duas bases estaduais, com troca automática. O serviço consulta passou a ter uma base reserva: se a base principal falhar (indisponibilidade, erro 5xx ou tempo esgotado), a mesma consulta é refeita na outra base, sem nova cobrança e sem você repetir a chamada. Na prática, menos erro_codigo: PROVIDER_UNAVAILABLE e menos estorno. Nenhum campo mudou de nome ou tipo no JSON de dados: as duas bases são traduzidas para o mesmo formato, e o tri-estado (vazio significa não informado, nunca “nada consta”) continua valendo. Duas consequências que podem exigir ajuste de quem já integra:
  • comunicacaodevendas deixou de ser garantido: Atenção. A base que hoje atende a maioria das consultas não tem campo próprio de comunicado de venda; ele só vem preenchido quando a base registra a ocorrência. Em GET /public/capacidades o item comunic_venda caiu de garantido para condicional. Campo vazio aqui significa “não informado”: nunca “não há comunicado de venda”. Quem exibe esse dado ao usuário final precisa tratar o vazio como ausência de informação, não como negativa. O mesmo vale para exerciciolicenciamento, que em parte das consultas vem só como data-limite.
  • O PDF pode vir emitido pela base ou desenhado pela ZapCar. O GET /v1/consultas/:id/pdf continua entregando um documento com as mesmas seções, mas a origem agora depende de qual base atendeu: a principal emite o próprio documento (e é ele que você recebe); a reserva não emite, e aí o PDF é o que a ZapCar desenha no mesmo layout. Se o seu fluxo depende de posição de texto, carimbo ou extração do PDF, use o JSON de dados: ele é idêntico nos dois casos.

16/09/2026

  • CRLV: Amazonas (AM) agora atendido. A emissão do CRLV de AM entrou na API: exige só placa + uf, sem CPF nem RENAVAM. O estado já tinha preço cadastrado e nenhum emissor; agora tem. Confirme o preço e os campos em GET /v1/servicos → crlv.preco_por_uf.

11/09/2026

  • Novo: a logo da sua empresa nos PDFs (white-label). Quem cadastra a logo no portal (Configurações › Personalização dos PDFs) passa a receber, no GET /v1/consultas/:id/pdf, o relatório com a identidade da própria empresa. Vale para consulta, consulta-completa, gravame, renajud e para os relatórios desenhados pela ZapCar (debitos, debitos-estadual, decodificacao-chassi, decodificacao-motor, score-credito). Quando o documento é o emitido pela base, a logo é aplicada na cópia servida, no topo da 1ª página, e o conteúdo é deslocado para baixo (nada é encolhido); o arquivo gravado não muda. Documentos oficiais (crlv, ATPV-e, código de segurança) seguem intactos. A logo é sempre a do dono da chave de API. Nada mudou no endpoint, no content-type nem no JSON de dados, mas se você extrai texto do PDF por posição, revise: a 1ª página ganha uma faixa no topo e a paginação pode mudar. Sem logo cadastrada, o PDF continua exatamente como era.

09/09/2026

  • Consulta Simples: nova base estadual; o PDF passa a ser desenhado pela ZapCar no mesmo layout. O serviço consulta passou a ser atendido por outra base estadual. Nenhum campo mudou de nome ou tipo no JSON de dados; o tri-estado (vazio significa não informado, nunca “nada consta”) e o bloco nao_verificado continuam iguais. Duas mudanças aditivas: comunicacaodevendas volta a vir preenchido (a base nova informa o comunicado de venda) e exerciciolicenciamento volta a trazer o ano do último licenciamento; origem_de_emplacamento passa a vir vazio. O GET /v1/consultas/:id/pdf continua entregando um documento no mesmo layout de antes (mesmas seções: dados da consulta, quadro de avisos, resumo, informações do veículo, multas e débitos, restrições, proprietário), agora gerado pela ZapCar a partir dos dados, porque a base nova não emite documento próprio. Itens que a base não respondeu saem como NÃO INFORMADO, não como “nada consta”. Se você usa o JSON (recomendado), nada a fazer.
  • Consulta Simples: nova versão da base estadual (V2). O serviço consulta passou a ser atendido pela versão 2 da base estadual da mesma fonte (segunda troca de versão em dois dias; a anterior foi em 08/09). Nenhum campo mudou de nome ou tipo no JSON de dados; o tri-estado (vazio significa não informado, nunca “nada consta”) e o bloco nao_verificado continuam iguais. Campos condicionais como exerciciolicenciamento, origem_de_emplacamento e os valores de débito seguem vindo quando a base os devolve. O GET /v1/consultas/:id/pdf continua entregando o documento emitido pela base; como a versão mudou, o layout e a paginação do arquivo podem variar de novo: se você extrai texto do PDF por posição, revise. Se você usa o JSON (recomendado), nada a fazer. Um eventual retorno à versão anterior é feito do nosso lado, sem mudança no contrato.
  • Janela de polling: Atenção. A base estadual que atende a Consulta Simples e a Consulta Completa passou a levar até ~2 minutos numa placa consultada pela primeira vez no dia (medido em produção em 09/09; a mesma placa, repetida, volta em segundos). Quem desiste em 60s, como o exemplo antigo desta página fazia, abandona uma consulta que vai concluir e que já foi debitada. Recomendação nova: intervalo de 3–5s e teto de 5 minutos, ou, melhor, o webhook query.completed, que dispensa o polling. processando nunca é erro. Nada mudou no contrato da API: mesmos endpoints, mesmos campos.
  • Correção: falhas em série por “serviço indisponível”. Entre 08/09 (10:46) e 09/09 (09:30), consultas do serviço consulta falharam com erro_codigo: CIRCUIT_OPEN e retryable: true sem que a base fosse consultada: um defeito interno nosso na proteção contra fornecedor fora do ar, já corrigido. Todas foram estornadas automaticamente. Se você guardou essas placas como problemáticas, pode reprocessá-las.

08/09/2026

  • Consulta Simples: trocou a versão da base estadual. O serviço consulta passou a ser atendido por outra versão da base estadual da mesma fonte. Nenhum campo mudou de nome ou tipo no JSON de dados, e o tri-estado (vazio significa não informado, nunca “nada consta”) continua igual. Mudança aditiva: exerciciolicenciamento e origem_de_emplacamento, que vinham sempre vazios desde 28/08, voltam a vir preenchidos quando a base os devolve. O GET /v1/consultas/:id/pdf continua entregando o documento emitido pela base; como a versão da base mudou, o layout e a paginação do arquivo podem variar: se você extrai texto do PDF por posição, revise. Se você usa o JSON (recomendado), nada a fazer.

02/09/2026

  • Novo: erro_codigo na consulta que falhou. O GET /v1/consultas/:id com status: "erro" passa a trazer um código estável do motivo (PROVIDER_TIMEOUT, QUERY_NOT_FOUND, INVALID_PLATE…) e o campo erro passa a descrever o que aconteceu em vez da frase genérica. O retryable agora deriva desse código. A lista completa está em Consultar o resultado.
  • Novo: proteção contra pedido duplicado. Se você enviar o mesmo serviço para o mesmo identificador (placa, chassi, motor ou documento) enquanto a solicitação anterior ainda está em processamento, o POST /v1/consultas responde 200 com reaproveitada: true, o id da consulta existente e valor_cobrado: 0: nada é cobrado de novo. Vale para retry de rede e para reenvio por engano. Continue usando Idempotency-Key quando puder: ela cobre também o caso em que a primeira consulta já terminou.
  • Comportamento: falha definitiva termina mais rápido. Quando a base responde “veículo não encontrado” ou o dado enviado é inválido, a consulta vai para erro na primeira tentativa, sem as retentativas internas que antes atrasavam o resultado em vários minutos. Falhas transitórias (base fora do ar, timeout) continuam sendo retentadas.
  • Comportamento: estorno automático. Toda consulta que termina em erro é estornada automaticamente; um processo de reconciliação confirma o estorno mesmo se houver falha momentânea no momento do erro. O campo erro informa quando o valor foi devolvido ao saldo.
  • Novo: FIPE dentro da Consulta Completa. Envie "incluir_fipe": true no POST /v1/consultas com servico: "consulta-completa" e o resultado traz dados.fipe, no mesmo formato do POST /v1/fipe: uma chamada só. O preço da FIPE é somado ao da Completa (veja opcionais.incluir_fipe.preco_adicional no GET /v1/servicos). Se a FIPE não estiver disponível para a placa, a Completa é entregue normalmente, dados.fipe vem null com dados.fipeErro, e só a parcela da FIPE é estornada.

29/08/2026

  • Atenção: mudou o layout dos PDFs que a ZapCar desenha. Em debitos, debitos-estadual, decodificacao-chassi, decodificacao-motor e score-credito, o GET /v1/consultas/:id/pdf passou a entregar o arquivo no mesmo padrão visual dos documentos emitidos pelas bases, seções em faixa, grade “rótulo: valor” e quadro de avisos, para que todos os PDFs da plataforma tenham a mesma cara. Nada mudou no endpoint, no content-type, no fluxo nem no JSON de dados: muda o layout e a paginação. Se você extrai texto do PDF por posição, recorta páginas ou espera um número fixo de folhas, revise. Se você usa o JSON (recomendado), nada a fazer.
  • Gravame e RENAJUD: o mesmo vale para o relatório de reserva. Esses dois entregam o documento da base desde 28/08; o relatório ZapCar que aparece quando a base não emite documento também passou para o novo padrão visual. Nenhuma mudança de campo.
  • Score ZapCar: onde ele está. Lembrete, não mudança: o score de risco 0–100 da Consulta Completa vem no JSON (risco no GET /v1/consultas/:id) e no painel. Ele não está no PDF desde que a Completa passou a entregar o documento da base: se você o exibe para o seu usuário, leia do JSON.

28/08/2026

  • Atenção: o PDF mudou de documento. Em consulta, consulta-completa, gravame e renajud, o GET /v1/consultas/:id/pdf passou a entregar o documento emitido pela própria base consultada, e não mais o laudo desenhado pela ZapCar. O endpoint, o content-type e o fluxo são os mesmos, o que muda é o layout e a paginação do arquivo. Se você extrai texto do PDF por posição, recorta páginas ou espera um número fixo de folhas, revise. O JSON de dados não mudou por causa disso.
  • Atenção: serviço historico-proprietarios descontinuado. O slug saiu do catálogo e novas consultas são recusadas. O campo historico_proprietarios não é mais devolvido em consulta nenhuma, inclusive na Completa: nenhuma fonte do stack entrega a cadeia de donos anteriores. Todas devolvem apenas o proprietario atual. A relação de donos consta na certidão de prontuário do DETRAN de emplacamento. (Revertido em 22/09/2026, ver acima.)
  • Gravame: mais de um registro por veículo. dados.ocorrencias[] passa a trazer todos os registros de gravame do veículo, cada um com agente financeiro, documento, número do gravame, contrato e datas. Os campos de topo continuam descrevendo o registro principal, sem mudança de nome ou tipo: é aditivo. O documento oficial da base lista todos.
  • Gravame: novos campos do veículo. marcamodelo, cor, municipio, combustivel e motor passam a vir preenchidos quando a base os devolve. Antes não existiam nesse serviço.
  • RENAJUD: base sem resposta agora é ERRO, não “nada consta”. Quando a base de restrições judiciais não responde, a consulta falha (com estorno) em vez de devolver um veículo limpo. Se o seu código tratava resposta vazia como “sem bloqueio”, esse caso deixou de existir: passe a tratar o erro.
  • Novo: retryable na consulta que falhou. O GET /v1/consultas/:id com status: "erro" passa a trazer retryable: true quando a base caiu e a mesma consulta tende a funcionar minutos depois, false quando repetir só muda a fatura (placa inexistente, contrato, credencial). O campo é OMITIDO quando não classificamos: ausente significa “não sabemos”, e não false. Trate os três casos.
  • Gravame: codigofinanceira agora vem null, e o número do registro ganhou campo próprio. A base atual não devolve código de financeira: devolve o CNPJ dela, que já estava em documentofinanceira. O número do gravame no SNG, que antes ia empurrado para codigofinanceira por falta de lugar, passou a ter o campo numerogravame. Se você lia codigofinanceira esperando o número do registro, migre para numerogravame.
  • Atenção: documento do proprietário pode vir MASCARADO. Algumas bases devolvem o CPF/CNPJ do titular parcialmente ("***.490.411-**"). Antes nós removíamos a pontuação de tudo, e a máscara virava "490411": seis dígitos que pareciam um documento e não eram. Agora a pontuação só sai quando restam 11 ou 14 dígitos; fora disso o valor volta como a base mandou. Valide o tamanho antes de usar: veiculo.proprietario.documento nem sempre é um documento completo, e tipoDocumento vem null quando não dá para afirmar.
  • Consulta Simples: o PDF também passou a ser o documento da base. Vale o mesmo aviso do item de cima sobre layout e paginação. Quando a base não emite documento, o relatório ZapCar continua sendo entregue: o endpoint responde igual nos dois casos.
  • Consulta Simples: duas reduções de cobertura. comunicacaodevendas passou a vir vazio (a fonte atual não tem o campo; vazio significa não informado, nunca “nada consta”). E datalicenciamento traz a data limite do licenciamento, não mais o ano do exercício: exerciciolicenciamento vem vazio.

27/08/2026

  • Atenção: dados.debitos da Consulta Completa deixou de sair zerado. O bloco sempre devolvia 0 em todos os itens; agora traz os valores reais apurados na consulta, mais estado por item (SEM_DEBITO, CONSTA, CONSTA_SEM_VALOR, NAO_INFORMADO) e total_parcial. Se o seu código assumia zero: somando esse bloco a outro, ou pulando a seção de débitos, revise. total_parcial: true significa que existe débito sem valor informado: o total é um piso. E debitos: null é “não verificado”, não “não deve”.
  • Novo endpoint: imagens da Consulta Completa. GET /v1/consultas/:id/imagens/:tipo/:indice entrega as fotos de leilão, as imagens de vistoria/anúncio e o certificado do laudo CSV. Elas não viajam mais dentro do JSON (o retorno passava de 8 MB): fotosLeilao agora é uma lista de indice + url. Detalhes em Imagens da Consulta Completa.
  • Novo bloco dados.renainf. Infrações RENAINF cometidas fora da UF de emplacamento, com auto, enquadramento, órgão autuador, valor e situação de pagamento. Três estados: null = base não respondeu, total: 0 = respondeu sem infração, total: N = há infrações. Não some RENAINF aos débitos estaduais: são universos diferentes, e a soma inventa um total que não existe.
  • Novo bloco dados.csv: Certificado de Segurança Veicular. Sinal forte: o CSV é exigido depois de alteração ou reparo estrutural. O campo observacao traz a ressalva da fonte e deve ser repassada junto com o dado. A maior parte do conteúdo está dentro da imagem do certificado, em imagem_url.
  • Novos blocos dados.blocos e dados.offline: o terceiro estado, explícito. blocos diz, base por base, se ela respondeu e quantas ocorrências trouxe; offline: true avisa que a resposta veio de cache da fonte, não da base viva. Use os dois antes de escrever “nada consta” para o seu cliente.
  • Novo bloco dados.informacoesAvulsas. Pares descrição/valor do registro (status e vencimento do licenciamento, instituição alienadora, indicadores extrajudiciais). Vem a lista inteira, então campo novo aparece aqui em vez de sumir.
  • restricoes ganhou restricaoGeral e veiculoBaixado. restricaoGeral é um indicador amplo e não equivale a restrição administrativa: ele acende até por multa RENAINF. O texto real está em restricao1..4. Tratar os dois como sinônimo inventa impedimento de transferência.
  • Reforço de tri-estado. Mais campos de restricoes passam a devolver null quando a fonte não verificou o item, em vez de false. if (!restricoes.sinistro) trata “não verificado” como “sem sinistro”: teste os três estados.
  • O que a Completa não traz. anoUltimoLicenciamento pode vir null, e o bloco leilao (lote, pátio, data, comitente) costuma vir null: as fotos continuam chegando em fotosLeilao. O campo historicoProprietarios deixou de existir em 28/08/2026: a cadeia de donos anteriores não é mais entregue por nenhuma consulta, as fontes atuais devolvem apenas o proprietário atual. (Revertido em 22/09/2026: a cadeia voltou como serviço avulso historico-proprietarios; na Completa o campo segue ausente: ver acima.)

26/08/2026

  • Consulta Completa: bloco veiculo mais completo. O bloco normalizado ganhou ficha_pesados (eixos, capacidade de carga, peso bruto total, capacidade de tração e tanque, preenchido só em caminhão, ônibus e implemento) e faturamento (tipo_documento, documento e uf de quem recebeu o veículo 0km). Aditivo: nenhum campo existente mudou de nome ou de tipo.
  • Leilão agora tem três fontes. veiculo.leilao ganhou o contador fotos. A foto do veículo em pátio é prova positiva por si só: quando fotos > 0, o veículo passou por leilão mesmo com ocorrencias: 0, isso significa apenas que a base de ocorrências não trouxe lote e comitente. leilao: null continua sendo “nenhuma fonte verificou”.
  • Débito confirmado sem valor agora aparece. Quando a base do estado responde “existe débito, valor não informado”, o item entra em veiculo.debitos[] com valor_centavos: 0 e valor_informado: false. Antes ele era descartado e a resposta parecia dizer “sem débito” sobre um carro devendo. Nunca some valor_centavos sem olhar valor_informado: o total é um piso, não o devido.
  • Atenção: veiculo.sinistro pode vir null. O provedor devolve null nesse campo quando não verifica, e passamos a preservar isso em vez de converter para false. Se o seu código faz if (!veiculo.sinistro), ele passou a tratar “não verificado” como “sem sinistro”. Teste os três estados: true, false e null. O mesmo vale para recall.
  • CRLV: Mato Grosso do Sul (MS) agora atendido. A emissão do CRLV de MS entrou na API: exige só placa + uf, sem CPF nem RENAVAM. O estado tinha preço cadastrado mas nenhum emissor; agora tem. Confirme o preço em GET /v1/servicos → crlv.preco_por_uf.
  • Novo serviço: 2ª via do ATPV-e. Emissão da Autorização para Transferência de Propriedade de Veículo eletrônica. Slug atpve; exige a placa, sem uf, sem cpf, sem renavam (desde 23/09/2026, também a declaração aceite_atpve; ver 2ª via do ATPV-e). Entrega documento em PDF (não devolve JSON de dados). Cobertura nacional e preço único, diferente do crlv, que é por UF.
  • É emissão, não consulta. Leva cerca de 1 minuto. O status fica processando nesse intervalo: amplie o polling ou use o webhook query.completed em vez de desistir em 30s.
  • Consulta Completa: fotos de leilão. A Completa passa a trazer o bloco dados.fotosLeilao: imagens do veículo em pátio de leilão, quando existirem, e também no PDF do laudo. É aditivo: nenhum campo existente mudou. Três estados, iguais aos do bloco leilao: null = a base de imagens não respondeu (não verificado), [] = respondeu e não há foto, lista = fotos encontradas. null e [] significam coisas diferentes: ausência de foto não prova ausência de leilão.

06/08/2026

  • Novo serviço: Score de Crédito. Análise de crédito e localização por documento (CPF ou CNPJ, sem placa): dados da Receita Federal, score, renda presumida, e-mail/endereço presumidos e participação em empresas. Slug score-credito; entrega JSON (dados) e PDF.
  • Novo serviço: Débitos Estaduais. Débitos do veículo direto na base do estado (IPVA, licenciamento, DPVAT, multas e dívida ativa). Slug debitos-estadual; exige placa, uf e renavam, e, em algumas UFs, documento (CPF/CNPJ) ou chassi (ver debitos-estadual.campos_por_uf em GET /v1/servicos). Não confundir com debitos (código de barras, agregado).

12/08/2026

  • CRLV: Pernambuco (PE) agora atendido. A emissão do CRLV de PE já está disponível na API: exige só placa + uf. Confirme o preço e os campos em GET /v1/servicos → crlv.preco_por_uf.

04/08/2026

  • Novo endpoint: Tabela FIPE por placa. POST /v1/fipe devolve os valores FIPE do veículo na mesma chamada (endpoint síncrono: sem id, sem polling, sem PDF). Custa R$ 0,25 por consulta, com estorno automático se falhar ou não houver FIPE. Detalhes em POST /v1/fipe.

31/07/2026

  • Novos serviços: Decodificação de Chassi e de Motor. Decodificam um chassi ou número de motor (sem placa) em dados do veículo + sugestões da Tabela FIPE. Slugs decodificacao-chassi e decodificacao-motor; entregam JSON (dados) e PDF.
  • CRLV: mais estados atendidos. Consulte sempre a lista viva em GET /v1/servicos → crlv.preco_por_uf.
  • CRLV: 2ª via automática (melhoria transparente). Se a 1ª via falhar, tentamos um provedor alternativo automaticamente. Você não muda nada: só aumenta a taxa de sucesso.
  • Catálogo mais preciso. O requer de cada serviço em GET /v1/servicos agora reflete os campos certos (ex.: chassi/motor nas decodificações e os campos por UF no CRLV).
Atenção:
Atenção, quem emite CRLV: alguns estados passaram a exigir cpf (CPF/CNPJ) e/ou renavam além de placa e uf. Hoje: CPF + RENAVAM em BA, PA, SP, TO, MT · só CPF/CNPJ em MG · só RENAVAM em PR, PI · só placa + uf em RJ e demais. Emitindo sem os campos exigidos, a resposta é 400 CRLV_DADOS_OBRIGATORIOS. Antes de emitir, leia o requer da UF em crlv.preco_por_uf.