Saltar al contenido principal
El SDK de Node trae definiciones TypeScript completas, reintentos automáticos y un método tipado por cada endpoint de OrigoID. Funciona en cualquier runtime Node 18+ y en Deno.

Instalación

Paquete en npm: @origoid/sdk. Código en github.com/origoid/sdk-node (público, para auditar).

Inicializa el cliente

Ese es todo el setup — no hay nada más que configurar. Nunca hardcodees la API key. Cárgala desde process.env, un secrets manager (Vault, 1Password, Doppler, etc.), o la capa de config de tu plataforma.

Tu primera llamada

El ejemplo usa PELJ900101HDFRRN09, un CURP sintético de los ejemplos del OpenAPI — no es CURP de persona real. Reemplázalo con el CURP que necesites validar.
Cada método devuelve la misma shape Envelope: { status, type, message, data, transactionId, processedAt, billable, errors? }. Ver Envelope de respuesta para el contrato completo.

Métodos por recurso

El cliente agrupa operaciones bajo una propiedad por dominio regulatorio.

client.authentication

client.renapo

client.sat

client.imss

client.ine

client.compliance

Nota: el método para la lista SAT 69-B es searchSat69B (con B mayúscula). Los demás métodos de compliance siguen el patrón regular camelCase.

client.biometrics

client.email

client.proofOfAddress

Manejo de errores

El SDK distingue entre errores de negocio (vienen dentro del envelope) y errores de transporte (lanzados como excepciones tipadas).

Errores de negocio — léelos del envelope

Para cualquier respuesta HTTP 200, incluyendo INVALID_REQUEST, el SDK devuelve un objeto Envelope normal. Revisa status y type antes de usar data:

Errores de transporte — try/catch

Para 401, 429 y fallas de transporte irrecuperables el SDK lanza errores tipados:

Configuración por llamada (avanzado)

Cada método acepta un segundo argumento opcional:
Lee esto antes de tunear timeouts o retries. El SDK sólo reintenta errores 5xx y fallas de red, nunca respuestas de negocio exitosas — entonces los retries no crean llamadas duplicadas facturables cuando el API respondió correctamente. crean llamadas extra cuando el request realmente falló: un request que hace timeout tres veces puede consumir tres créditos si la llamada eventualmente tuvo éxito en un intento posterior.
  • Los defaults (timeoutInSeconds: 60, maxRetries: 2) son correctos para casi cualquier workload. Cambia sólo con razón específica.
  • Combinar timeout largo con maxRetries alto (ej. 120s × 5) significa que un único request fallando puede ocupar un thread cliente hasta 10 minutos — malo para tu throughput y tu infraestructura.
  • Sobrescribe per-call sólo en endpoints con cold starts lentos conocidos (algunas llamadas de compliance y de lista INE).

TypeScript

Cada tipo de request y response se exporta bajo el namespace OrigoidApi:

CommonJS

El paquete trae ambos entry points ESM y CJS. En proyectos CommonJS:

Uso desde navegador

No llames a OrigoID directo desde un navegador. Las API keys son credenciales de larga vida con acceso facturable a tu cuenta; en el momento que una key llega al bundle del navegador, a la consola, o a local storage, queda efectivamente pública y en riesgo de abuso — del mismo modo que nunca pondrías la secret key de un procesador de tarjetas en código del lado cliente. El patrón correcto es backend-for-frontend (BFF): tu navegador habla con tu servidor, tu servidor guarda la API key y llama a OrigoID desde un ambiente confiable (Node, Python, Go). Si tu caso de uso genuinamente requiere llamadas directas desde navegador (widget de partner, formulario embebido, etc.) podemos habilitar CORS para tus orígenes específicos. La key sólo permanece segura si la escopeas con cuidado y la complementas con restricciones de referrer/origen — te ayudamos a diseñar ese flujo. Contáctanos y trabajamos la arquitectura contigo.