CASO DE USO

Filtrá data malformada antes de pagar a vendors downstream

Cada call a KYC, SMS provider, credit bureau o payment rail cuesta. Y cobran por intento, no por éxito. Cuando el input es estructuralmente malformado, pagás esos calls sin obtener nada. Normadata corre como middleware entre tu code y tus paid vendors.

O PROBLEMA

Los paid vendors no devuelven el cargo si el input es malformado

El modelo de pricing estándar es pay-per-request. KYC providers, SMS providers, bureaus, rails — todos cobran cada vez que les mandás algo, independiente de si el dato es válido. Filtrar pre-call es ROI directo.

KYC cobra por seat incluso si el CPF es garbage
Sumsub/Truora/Didit/Idwall/Metamap cobran el seat cuando inicia el flow. Si el CPF llegó con DV malo, el flow termina inmediato pero el seat se factura.
SMS provider cobra por intent de envío
Twilio/Sinch/MessageBird/Vonage cobran cada SMS attempted. Si el phone llega sin country code o con formato roto, el carrier rechaza pero el SMS attempt ya está cobrado.
Credit bureau cobra por consulta exitosa o rechazada
Equifax/Boa Vista/Veraz cobran cada query. Si el tax ID tiene DV malo, la query falla y el bureau te factura igual. Multiplicado por 10.000 consultas/mes, es real money.
POR QUE AS SOLUCOES PADRAO NAO SAO SUFICIENTES

Por qué los paid vendors no filtran ellos mismos

Esperar que el vendor mejore su validation
Su business model es pay-per-request. Cero incentivo en rechazar pre-cobro.
Negociar pricing por valid-only
Algunos lo aceptan en contratos enterprise. Para tier medio, raro. Y no aplica a tier startup.
Custom validation antes del call
Funciona pero requiere mantener algoritmos de DV de cada país. Cuando agregás un país, agregás librería + tests + dependencies.
COMO O NORMADATA AJUDA

Como o Normadata ajuda

POST /v1/verify (smart parse) como middleware entre tu code y el paid vendor. Si valid=false, short-circuit — no llamás al vendor.
Para inputs específicos (phone-only antes de SMS, tax_id-only antes de bureau), usá el endpoint específico (/v1/verify/contact o /v1/verify/tax-id) — menos overhead.
Track el rate de valid:false en tu telemetry. Si es alto, el ROI del filter es alto. Si es bajo, está sirviendo igual pero como insurance — el costo extra es marginal.
VEJA EM ACAO

Veja em acao

# Middleware gate — before any paid downstream call
$ curl -X POST api.normadata.io/v1/verify \
  -H "X-API-Key: nd_a8f3b2c1d4e5f6g7h8i9j0k1l2m3n4o5" \
  -d '{"country":"MX","value":"GOMJ881217"}'

{
  "valid": false,
  "errors": ["invalid_length"]
}

# → DO NOT call KYC vendor (saved $1.50)
# → DO NOT send SMS OTP (saved $0.04)
# → DO NOT query credit bureau (saved $0.80)

# Track the valid:false rate to forecast monthly savings:
#   invalid_inputs * (cost_per_kyc + cost_per_sms + cost_per_bureau)
LIMITACOES

Lo que Normadata no hace como middleware

No reemplaza a tus paid vendors. Es un filter — solo evita que les mandes garbage.
No audita las facturas de tus vendors. Para eso usá tu billing reconciliation tool.
PERGUNTAS FREQUENTES

Perguntas frequentes

¿Cuánto ahorro típicamente?
Depende de la calidad de tus inputs. Funnels mobile-first LATAM ven 10-25% de inputs con errores estructurales. Filtrarlos reduce paid-vendor cost por ese factor (con cost de Normadata por debajo del cost de un vendor downstream típico).
¿Dónde lo pongo en el flow?
Middleware en tu service de onboarding/payments — entre tu code y la llamada al vendor. O step en tu workflow engine (Temporal, Airflow, n8n) antes del step que llama al paid vendor.

Integre o Normadata no seu stack

Acesso antecipado. Entre na lista e daremos acesso à API.