CASO DE USO
Marketplace multi-país: uma API no lugar de cinco bibliotecas
Você opera em 5+ países LATAM. Cada um tem seu tax ID, seu algoritmo de DV, seu formato bancário. Hoje você tem uma biblioteca por país × uma por linguagem do seu stack — Node + Python + Go × Brasil + Argentina + México + Colômbia + Chile. Isso é um inferno de manutenção. A Normadata substitui tudo com uma REST API.
O PROBLEMA
Manter N bibliotecas por país × M linguagens não escala
Cada biblioteca tem sua própria cadência de releases, seus próprios bugs, sua própria interpretação do DV. Quando um país muda o formato (raro mas acontece), você precisa atualizar N × M dependências.
Drift entre bibliotecas de linguagens diferentes
validator-rut-cl em Node valida "K" mas validator-rut-cl em Python rejeita "K" minúsculo. O front aceita o RUT, o backend rejeita, o seller liga pro suporte.
5+ bibliotecas por país no seu monorepo
cpf-cnpj-validator + cuit-validator + ruc-pe-validator + rut-cl-validator + nit-co-validator + iban-validator. Cada uma mantida por uma pessoa diferente. Quando uma é abandonada (costuma acontecer), seu monorepo fica com um fork interno que ninguém mantém.
Onboarding multi-país exige routing por jurisdição
O seller escolhe país → seu code chama a biblioteca correspondente. Um switch/case por país. Por linguagem. Por serviço. Por time que toca onboarding.
POR QUE AS SOLUCOES PADRAO NAO SAO SUFICIENTES
Por que OSS multi-país não escala
Bibliotecas OSS individuais
Grátis e rápido pra um país, mas o inferno começa no segundo. Zero envelope unificado entre bibliotecas — cada uma tem seu próprio shape de resposta.
Wrapper interno
Seu time escreve um wrapper sobre as 5 bibliotecas. Agora você mantém 5 bibliotecas + 1 wrapper. E o wrapper vira dívida técnica que ninguém quer tocar.
Validação server-side custom
Você escreve os algoritmos de DV você mesmo. Funciona até o formato mudar ou ser adicionado um país. E seu time-to-add-country é 2 semanas em vez de 1 dia.
COMO O NORMADATA AJUDA
Como o Normadata ajuda
POST /v1/validate/tax-ids com o payload do signup. Você passa country e type por item; o envelope batch aceita 1 ou N (até 1.000).
Para chequeo determinístico por país: POST /v1/validate/tax-ids com country + type específicos. Mesmo envelope de resposta para todos os países cobertos.
Quando você adiciona um país novo, não adiciona biblioteca — só adiciona country no request body. Time-to-launch em um país novo cai de semanas pra horas.
VEJA EM ACAO
Veja em acao
# Validate the full applicant record at marketplace signup
$ curl -X POST api.normadata.io/v1/validate/records \
-H "X-API-Key: nd_a8f3b2c1d4e5f6g7h8i9j0k1l2m3n4o5" \
-d '{"items":[
{"reference_id":"app-77","country":"BR",
"tax_id":"111.444.777","email":"loja@exemplo.com","name":"Loja Exemplo"}
]}'
{
"results": [
{
"reference_id": "app-77",
"fields": {
"tax_id": { "valid": false, "error": "invalid_length" }
},
"readiness": {
"billing": { "status": "blocked", "reason": "tax_id is invalid" }
}
}
]
}
# Multi-country signup: one endpoint for AR, BR (live), CL, CO, PE, UY (beta)...
# Replace several country-specific libs with one consistent APILIMITACOES
O que a Normadata não faz em marketplace onboarding
—Não auto-routea conforme jurisdição legal. Se o seller tem CUIT mas está operando no Brasil, isso é problema do seu rule engine de compliance — a Normadata só diz que o CUIT é estruturalmente válido.
—Não detecta sellers fraudulentos. Format-only — fraude usa identifiers válidos.
PERGUNTAS FREQUENTES
Perguntas frequentes
Funciona se meu backend está em Go e o front em TypeScript?
Sim. A API é REST + JSON — qualquer linguagem que faça fetch serve. /docs/examples tem cURL, TypeScript, Python e Go.
Quanto custa vs manter 5 bibliotecas?
Depende do volume e do custo interno de manutenção. A métrica mais honesta: tempo do seu time. Se seu eng team gasta 1 dia/mês por país que toca biblioteca, essa hora vale muito mais que o call à API.
Integre o Normadata no seu stack
Acesso antecipado. Entre na lista e daremos acesso à API.