Saltar al contenido principal
El SDK de Python trae clientes sync y async, modelos de respuesta tipados (sobre Pydantic, la librería estándar de validación de datos en Python), type hints completos, y un método tipado por cada endpoint de OrigoID.

Instalación

O con uv / poetry / pdm:
Paquete en PyPI: origoid. Código en github.com/origoid/sdk-python (público, para auditar). Requiere Python 3.9 o más reciente.

Inicializa el cliente

Ese es todo el setup — no hay nada más que configurar. Nunca hardcodees la API key. Cárgala desde os.environ, un .env via python-dotenv, o un secrets manager (HashiCorp Vault, 1Password, Doppler, etc.).

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 una instancia Envelope: { status, type, message, data, transaction_id, processed_at, billable, errors? }. Ver Envelope de respuesta para el contrato.

Métodos por recurso

Los métodos están agrupados por dominio regulatorio. Los nombres usan snake_case Python.

client.authentication

client.renapo

client.sat

extract_csf y validate_cfdi aceptan un dict request= porque los schemas subyacentes permiten shapes alternativas (identificadores directos O upload de documento). Dentro del dict usa los nombres camelCase del wire JSON:

client.imss

client.ine

client.compliance

client.biometrics

client.email

client.proof_of_address

Cliente async

Para aplicaciones sobre FastAPI, aiohttp, Starlette, u otros frameworks async, usa AsyncOrigoID. Mismos nombres de método, mismos argumentos, mismos tipos de retorno — sólo agregas await para que la llamada no bloquee el event loop mientras el HTTP request está en vuelo.
Para lanzar varias llamadas en paralelo (ej. validar varios CURPs al mismo tiempo), usa asyncio.gather — el mismo patrón que Promise.all en JavaScript:
Si tu aplicación no está construida sobre un stack async, usa OrigoID — async sólo aporta cuando necesitas manejar muchas operaciones concurrentes sin spawnear threads.

Manejo de errores

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

Errores de negocio — inspecciona el envelope

Para cualquier respuesta HTTP 200, incluyendo INVALID_REQUEST, el SDK devuelve un Envelope. Revisa status y type antes de usar data:
Ver Errores y Catálogos para el catálogo completo de códigos type.

Errores de transporte — try/except

Para 401, 429 y fallas irrecuperables el SDK lanza excepciones tipadas:

Configuración por llamada (avanzado)

Pasa request_options para override de timeout, retries o headers por llamada:
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 (60 s, 2 reintentos) son correctos para casi cualquier workload. Cambia sólo con razón específica.
  • Combinar timeout largo con max_retries alto (ej. 120 s × 5) significa que un único request fallando puede ocupar un thread hasta 10 minutos — malo para tu throughput y tu infraestructura.
  • Sobrescribe per-call sólo en endpoints con cold starts lentos conocidos.