Os critérios que uma consulta precisa cumprir para entrar no catálogo

A metodologia que usamos para aprovar ou reprovar um serviço antes de oferecê-lo — e por que o catálogo tem menos itens do que o provedor lista.

Publicado em 26/08/2026 · Revisado em 26/08/2026 · Equipe editorial ValidaData

Por que o catálogo é menor que a lista do fornecedor

O provedor com que trabalhamos lista mais serviços do que oferecemos. A diferença não é falta de integração: é reprovação nos critérios abaixo.

Oferecer um serviço que responde erro, ou cujo retorno ninguém conferiu, produz cobrança que vira estorno e cliente que não volta. Sai mais barato não oferecer.

Os cinco critérios

Um serviço só aparece no catálogo quando cumpre todos. Falhar em um basta para ficar de fora, e a regra é a mesma que o sistema aplica em tempo de execução — não é conferência manual.

  • Rota confirmada: o endereço da integração existe e está preenchido.
  • Verificação aprovada: o serviço respondeu no último teste contra o ambiente do provedor.
  • Texto conferido: alguém leu a resposta real e escreveu o que ela devolve, campo a campo. Descrição deduzida do nome não conta.
  • Formulário implementado: o tipo de entrada tem validação e máscara. Serviço que exige mais campos do que o formulário coleta mandaria pedido incompleto.
  • Fluxo compatível: serviços assíncronos só entram quando o acompanhamento estiver implementado — entregar um protocolo cobrado como se fosse o relatório seria vender o que não foi entregue.

O que fazemos quando um serviço quebra

A verificação roda periodicamente contra o provedor. Serviço que passa a reprovar sai da vitrine sozinho, sem intervenção — a mesma regra que o coloca lá o remove.

Isso é deliberado: preferimos um catálogo que encolhe silenciosamente a um catálogo que anuncia o que não funciona.

O que não entra de jeito nenhum

Busca por nome, listas de pessoas, localização de indivíduos e qualquer produto cuja proposta seja encontrar alguém. Não é limitação técnica — é escolha. Esses usos não passam no teste de finalidade legítima da LGPD, e um catálogo que os oferece atrai exatamente o cliente que não queremos.

Há um efeito prático nisso que vale dizer em voz alta: recusar esses produtos reduz o tamanho do mercado endereçável. É uma decisão comercial consciente, e não um acaso da integração.

Como escrevemos o texto de cada consulta

O texto sai da resposta, não do nome do serviço. Alguém executa a consulta no ambiente de homologação do provedor, lê a resposta campo a campo e escreve o que ela devolve — na ordem em que devolve, com o nome que o cliente entende.

Isso já evitou erro publicado. Um serviço chamado “recall” sugeria informação sobre campanhas de recall de fabricante; a resposta real não trazia campo algum sobre isso. O texto foi revertido e o serviço saiu do catálogo até que alguém confira o que ele de fato entrega.

É também por isso que o nome comercial costuma diferir do nome do provedor. “Agregados Basica” descreve um endpoint; “Histórico do veículo” descreve o que a pessoa está comprando.

Preço: como chegamos ao valor de cada consulta

O custo de aquisição de cada consulta é conhecido, e o preço ao cliente é definido sobre ele com uma margem que varia por família de serviço — consultas caras de histórico completo têm margem percentual menor que consultas simples de confirmação.

O que não fazemos é vender abaixo do custo para atrair volume: o sistema recusa salvar um preço abaixo do custo do provedor, justamente porque esse tipo de erro só aparece no fechamento do mês.

Fontes consultadas

  • Processo interno de verificação, executado contra o ambiente de homologação do provedor
  • Regra `FILTRO_PRONTO_PARA_CLIENTE`, aplicada em todas as telas do produto

Ver as consultas disponíveis

Cada consulta tem página própria, com o que você informa, o que volta na resposta e as limitações. Pagamento por consulta, sem mensalidade.

Ver o catálogo

Leia também