Saltar al contenido principal
El SDK de Go se distribuye como un módulo Go estándar. No hay registry separado — go get baja el código directo de GitHub. El SDK provee una función tipada por cada endpoint de OrigoID y sigue patrones Go idiomáticos (context.Context, structs exportados, errores explícitos).

Instalación

O agrega a go.mod:
Luego corre go mod tidy. Código en github.com/origoid/sdk-go (público, para auditar). Requiere Go 1.21 o más reciente.

Inicializa el cliente

Ese es todo el setup — no hay nada más que configurar. Nunca hardcodees la key. Léela de os.Getenv, viper, 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 (*origoid.Envelope, error). La shape del envelope es { Status, Type, Message, Data, TransactionId, ProcessedAt, Billable, Errors }. Ver Envelope de respuesta para el contrato.

Métodos por recurso

El cliente agrupa operaciones por dominio regulatorio.

c.Authentication

c.Renapo

origoid.String(...) es un helper para campos string opcionales (Go no tiene Option<T>; la opcionalidad se modela con punteros).

c.Sat

ExtractCsf y ValidateCfdi aceptan map[string]any porque los schemas permiten shapes alternativas (identificadores directos O upload de documento).

c.Imss

c.Ine

c.Compliance

c.Biometrics

c.Email

c.ProofOfAddress

Manejo de errores

El SDK distingue entre errores de negocio (vienen dentro del envelope) y errores de transporte (devueltos como error no nulo).

Errores de negocio — inspecciona el envelope

Para cualquier HTTP 200, incluyendo INVALID_REQUEST, el SDK devuelve un *Envelope normal. Revisa Status y Type antes de usar Data:

Errores de transporte — error no nulo

Para 401, 429, fallas de red, el SDK devuelve un error tipado:

Configuración por llamada (avanzado)

Usa helpers option.With* como argumentos adicionales:
Pasa un context.Context para respetar deadlines o cancelaciones del caller; el SDK respeta ctx.Done() y aborta requests en vuelo.
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 MaxAttempts alto (ej. 120 s × 5) significa que un único request fallando puede ocupar una goroutine hasta 10 minutos — malo para tu throughput y tu infraestructura.
  • Sobrescribe per-call sólo en endpoints con cold starts lentos conocidos.

Punteros para campos opcionales

Go no tiene Option<T>, así que los campos opcionales en structs de request son tipos puntero. El SDK expone helpers para hacerlo menos verboso:
Para enums: