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
go.mod:
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
os.Getenv, viper,
o un secrets manager (HashiCorp Vault, 1Password, Doppler, etc.).
Tu primera llamada
El ejemplo usaPELJ900101HDFRRN09, un CURP sintético de los
ejemplos del OpenAPI — no es CURP de persona real. Reemplázalo con
el CURP que necesites validar.
(*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 comoerror no
nulo).
Errores de negocio — inspecciona el envelope
Para cualquier HTTP 200, incluyendoINVALID_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 helpersoption.With* como argumentos adicionales:
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. Sí 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
MaxAttemptsalto (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 tieneOption<T>, así que los campos opcionales en structs de
request son tipos puntero. El SDK expone helpers para hacerlo menos
verboso: