Normadata API vs. librerías open source (python-stdnum, libphonenumber, etc.)
¿Cuándo conviene usar una librería OSS y cuándo una API hosted?
python-stdnum, libphonenumber, validador-py y similares son proyectos sólidos, maduros, gratuitos y self-hosted. No estamos diciendo que Normadata los reemplaza en todos los casos — sería deshonesto. Esta comparativa te explica con criterio técnico cuándo cada opción gana, y cuándo la API agrega valor real sobre las librerías.
Comparación rápida
| Aspecto | Librerías OSS | Normadata API |
|---|---|---|
| Costo | Gratis (MIT/LGPL) | Gratis en beta; pricing futuro no anunciado |
| ¿Self-hosted? | Sí — corre en tu infra, sin red externa | No — API hosted en normadata.io |
| ¿Multi-lenguaje? | Depende: python-stdnum es Python, libphonenumber tiene ports | Sí — HTTP, cualquier lenguaje |
| ¿Normalización incluida? | Parcial (depende de la librería) | Sí — forma canónica en cada respuesta |
| ¿Match / dedupe? | No — tenés que construirlo encima | No — pero devuelve la forma canónica normalizada, así dedup/match los hacés vos sobre un dato ya consistente |
| ¿Actualizaciones de specs? | Depende del mantenedor del proyecto OSS | Responsabilidad de Normadata |
| ¿Latencia? | ~0 ms (in-process) | <50 ms (red) |
| ¿Privacy / datos? | Total control — datos no salen de tu infra | Datos enviados a Normadata para procesamiento |
¿Cuándo usar cada uno?
- Monolito Python puro, ya tenés python-stdnum instalado y validás CUIT, CPF o RFC sin problemas.
- Requisito de cero llamadas de red: compliance interno, ambiente air-gapped, o latencia crítica sub-milisegundo.
- Privacy estricta: los datos personales no pueden salir de tu infraestructura bajo ningún contrato.
- Solo validación pura, sin necesidad de normalización ni de una forma canónica como base para tu propio dedupe.
- El identificador que necesitás ya está bien cubierto por una librería estable (ej. libphonenumber para teléfonos).
- Stack multi-lenguaje: tenés microservicios en Python, Go y JavaScript — una API en lugar de tres versiones de la misma lógica.
- Multi-país LATAM: necesitás CUIT, CPF, RFC, RUT, NIT, RUC en una sola integración consistente.
- Normalización automática: que '20-12345678-9', '20123456789' y ' 20 12345678 9' retornen la misma forma canónica.
- Base limpia para dedupe: la forma canónica que devuelve Normadata te deja comparar de forma confiable dos registros del mismo contribuyente con variaciones de formato (el dedup/match lo corrés vos sobre ese valor normalizado).
- Mantenimiento delegado: cuando el SAT cambia la spec del RFC o se agrega un nuevo prefijo de CUIT, Normadata lo actualiza.
- Respuesta JSON consistente: mismo schema de respuesta para todos los tipos de identificador, facilitando el manejo de errores.
Coverage real: qué identifica Normadata vs. python-stdnum
python-stdnum es un proyecto excelente con cobertura amplia — pero su fortaleza está en identificadores globales y europeos. Para LATAM, algunos identificadores están cubiertos (CPF, CNPJ, RFC, RUT-CL, CUIT), pero la cobertura no es uniforme y los módulos están divididos. Normadata está construido con foco exclusivo en LATAM: los identificadores disponibles en el catálogo incluyen CUIT, CUIL, DNI, CBU (Argentina), CPF, CNPJ (Brasil), RFC, CURP (México), RUT (Chile), NIT (Colombia), RUC (Perú), SSN, EIN, ITIN (EE.UU.), SIN, BN (Canadá) e IBAN. Todos con el mismo schema de respuesta.
El problema del stack multi-lenguaje
Una arquitectura común en startups LATAM: un backend Python (Django/FastAPI) para la lógica de negocio, un frontend Next.js para validación de formularios en el cliente, y workers Go o Node.js para procesamiento batch. Con librerías OSS, necesitás tres implementaciones distintas del mismo algoritmo de CUIT, y reconciliar los casos en que difieren. Con una API HTTP, hay una sola implementación que todos los lenguajes consumen de forma idéntica.
Trade-off honesto: OSS es gratis y self-hosted, Normadata es hosted
No vamos a venderles algo que no necesitan. Si tenés un stack homogéneo en Python, ya usás python-stdnum, solo necesitás validar CPF y CNPJ, y los datos no pueden salir de tu infra — la respuesta correcta es seguir con la librería OSS. Normadata agrega valor cuando el problema es multi-lenguaje, multi-país, o cuando necesitás una forma canónica consistente como base para tu propio dedupe/match. El costo post-beta no está anunciado, así que si el presupuesto es cero, OSS es la opción correcta hoy.
Ejemplos de código
from stdnum.ar import cuit
from stdnum.br import cpf, cnpj
from stdnum.mx import rfc
cuit.is_valid("20-12345678-9") # True
cpf.is_valid("111.444.777-35") # True
rfc.is_valid("XAXX010101000") # True
# But: no normalization, no consistent error schema,
# no match/dedupe, different API per country module.import httpx
def validate(items: list[dict]) -> list[dict]:
r = httpx.post(
"https://api.normadata.io/v1/validate/tax-ids",
headers={"X-API-Key": "nd_your_key"},
json={"items": items},
)
return r.json()["results"]
# Same schema for all countries — mix them in one batch (up to 1000 items)
validate([
{"id": "1", "value": "20-12345678-9", "country": "AR"}, # {"valid": true, "normalized": "20123456789", ...}
{"id": "2", "value": "111.444.777-35", "country": "BR"}, # {"valid": true, "normalized": "11144477735", ...}
{"id": "3", "value": "XAXX010101000", "country": "MX"}, # {"valid": true, "normalized": "XAXX010101000", ...}
])
# One endpoint, one schema for every country. Same call for 1 or N items.Normadata es una API hosted — los datos pasan por nuestra infraestructura. En beta, sin SLA formal. El costo post-beta no está anunciado. Para casos con requisitos estrictos de privacidad de datos, air-gapping, o presupuesto cero, las librerías OSS siguen siendo la opción correcta. Normadata no tiene SDK propietario — es HTTP puro, lo que es bueno para portabilidad pero significa que dependés de disponibilidad de red.
Preguntas frecuentes
¿python-stdnum cubre todos los identificadores LATAM?
Parcialmente. Tiene soporte para CUIT, CPF, CNPJ, RFC y RUT-CL entre otros. Pero algunos identificadores menos comunes o más recientes pueden tener cobertura incompleta, y los módulos están organizados por país con APIs ligeramente distintas entre sí.
¿Normadata tiene SDK?
No todavía. La integración es HTTP + JSON directamente. Eso significa que funciona con cualquier lenguaje sin dependencias adicionales, pero también que no hay helpers de tipo o autocompletado oficial. Durante la beta estamos evaluando si publicar SDKs livianos.
¿Qué pasa con libphonenumber para teléfonos?
libphonenumber de Google es el estándar de facto para teléfonos y está muy bien mantenido. Si tu necesidad es exclusivamente validación de números de teléfono, libphonenumber es probablemente la mejor opción. Normadata se enfoca en identificadores fiscales, personas, cuentas financieras y direcciones de LATAM; para validación de teléfonos hoy libphonenumber es más maduro para ese caso específico.
¿Puedo combinar python-stdnum con Normadata?
Sí, no son excluyentes. Un patrón común durante migraciones: usar python-stdnum para los identificadores que ya estás validando correctamente, y agregar Normadata para los nuevos países o tipos de identificador. Podés migrar progresivamente sin romper lo que ya funciona.
¿Qué significa que Normadata esté en beta privada?
Que el acceso requiere registro en la lista de espera, no hay SLA formal, y el pricing post-beta no está definido. La API funciona en producción y la validamos con carga real, pero no hay garantías contractuales de uptime ni SLA de respuesta todavía.