Skip to main content
El SDK de Midaz para Go es el cliente idiomático v4 para las API del ledger financiero de Midaz. Te da acceso tipado a todos los servicios (Organizations, Ledgers, Accounts, Transactions y más) con una sola superficie para autenticación, paginación, errores, registro y observabilidad.
¿Vienes de v2? v4 es una versión mayor de corte limpio con cambios incompatibles en autenticación, paginación, errores y acceso a servicios. No hay ventana de desuso. Cambias tu import de /v2 a /v4 y migras al mismo tiempo.Consulta Migración desde v2 antes de actualizar.

Primeros pasos


Paso 1 – Instala Go

Antes de usar el SDK, debes instalar Go en tu máquina. v4 declara Go 1.26 en go.mod. La API pública también usa iter.Seq2 y log/slog.
2
Descarga el instalador para tu sistema operativo (Windows, macOS o Linux).

Paso 2 – Crea o usa un proyecto de Go existente

Crea un proyecto de Go: Para crear un proyecto de Go, usa el siguiente comando:
Usa un proyecto de Go existente: Si trabajas en un proyecto existente, confirma que haya un archivo go.mod en la raíz. Si no lo hay, ejecuta el siguiente comando para crear uno:

Paso 3 – Agrega el SDK de Midaz

Dentro del directorio de tu proyecto, ejecuta el siguiente comando para obtener el SDK v4 y agregarlo a tus archivos go.mod y go.sum:
La ruta del módulo requiere el sufijo /v4. Si lo omites, Go resolverá una versión anterior a v4 desactualizada a la que le falta cada cambio incluido en esta versión. Importa siempre github.com/LerianStudio/midaz-sdk-golang/v4.
En VS Code o GoLand, tu IDE puede ejecutar go get automáticamente cuando importas un paquete nuevo.

Paso 4 – Importa el SDK

Crea o abre un archivo main.go y agrega el siguiente contenido. El ejemplo a continuación crea un cliente contra tu stack local de Midaz con autenticación anónima, lista organizaciones y luego crea una nueva.
El ejemplo a continuación apunta a un stack local de Midaz con la autenticación deshabilitada. Si aún no tienes uno en ejecución, consulta Primeros pasos con Midaz para ponerlo en marcha antes de ejecutar el fragmento.
Esto te da acceso a:
  • El cliente de Midaz para llamar a todos los servicios de la API.
  • Modelos de datos integrados (como CreateOrganizationInput).
  • Autenticación mediante Access Manager (producción) o Anonymous (desarrollo local).
  • Un sistema de configuración tipado que falla rápido en el momento de la construcción.
Para la configuración completa, consulta la sección Autenticación.

Paso 5 – Ejecuta el proyecto

Ejecuta el siguiente comando:

Arquitectura del SDK


Cada servicio es accesible directamente desde el cliente. Cada método de listado sigue la misma forma de trío. Cada error está estructurado. Cada opción falla rápido en el momento de la construcción.

Diseño en capas

Los servicios se acceden directamente desde el cliente: c.Accounts, c.Transactions, c.Organizations. Es posible que todavía veas un campo Entity incrustado en el autocompletado, pero el código nuevo debe usar los campos de servicio directos que se muestran en esta guía.
Para conocer el diseño detrás de la reescritura, consulta la guía de arquitectura.

Servicios

La capa Services es tu punto de acceso a cada dominio de Midaz. Cada servicio maneja una familia de recursos y ofrece todos sus métodos como parte de una única interfaz. No hay un interruptor UseAllAPIs() ni un paso de registro de servicios. Cada servicio está listo para usarse en cuanto midaz.New() retorna.

Servicios disponibles

Modelos

Cada tipo de modelo está estrechamente ligado a un concepto de negocio del mundo real. Los usarás en cada llamada de servicio, desde el alta de cuentas hasta el registro de transacciones con múltiples partidas. En v4, los tipos de modelo más comunes se reexportan directamente en el paquete midaz. Esto significa que midaz.Account y models.Account son el mismo tipo, y la mayoría del código solo necesita un import.

Tipos de modelo comunes

Para un builder, una forma de solicitud interna o un tipo obsoleto, importa github.com/LerianStudio/midaz-sdk-golang/v4/models directamente. Todos los tipos viven ahí, y los alias de midaz conservan la identidad de tipo, así que las dos rutas de import interoperan sin problemas.

Paquetes de utilidades

Dentro de la carpeta pkg del SDK, encontrarás paquetes de utilidades para el manejo de configuración, políticas de reintento y primitivas de seguridad. Se dividen en dos grupos. Los paquetes Core atienden preocupaciones transversales del SDK. Los paquetes Helper ofrecen utilidades específicas de dominio o de bajo nivel.

Paquetes Core

Paquetes Helper

El paquete pkg/access-manager de v2 se movió a pkg/auth (así el directorio coincide con el nombre del paquete). El paquete pkg/pagination de v2 se eliminó. Su superficie vive hoy en models y en cada servicio.

Autenticación


En v4, el SDK requiere exactamente una fuente de autenticación en el momento de la construcción. Llamar a midaz.New(...) sin ninguna de las dos retorna un error de configuración tipado. Ya no hay cascadas silenciosas de 401 en la primera llamada a la API. Tienes dos opciones:
  • midaz.WithAccessManager(...): OAuth con forma de producción a través del Lerian Access Manager. Se recomienda para cualquier stack que no sea local.
  • midaz.WithAnonymous(): renuncia por completo a la autenticación. Solo es adecuado para un stack local de Midaz con la autenticación deshabilitada.
Las dos opciones son mutuamente excluyentes.

Producción: Access Manager

Conecta tus credenciales de Access Manager en midaz.WithAccessManager. El SDK obtiene un token inicial de forma anticipada en el momento de la construcción, así que las configuraciones incorrectas aparecen como errores de configuración en lugar de cascadas de 401.
Reemplaza los valores del bloque // Configure Access Manager con tus propias credenciales antes de ejecutar.
El SDK solicita un token a tu Access Manager, lo adjunta a cada llamada a la API y lo renueva automáticamente cuando expira.

Desarrollo local: Anonymous

Para un stack local de Midaz con la autenticación deshabilitada, renuncia a ella de forma explícita:

Configura mediante variables de entorno

También puedes apuntar el SDK a tu Access Manager mediante variables de entorno. Expórtalas en tu shell o en tu gestor de procesos:
config.FromEnvironment() lee el entorno del proceso, no un archivo .env. Si mantienes las variables en un archivo .env durante el desarrollo, cárgalas con una biblioteca como godotenv antes de llamar a config.NewConfig(config.FromEnvironment()).
Luego activa la carga desde el entorno en el momento de la configuración:
La carga desde el entorno es explícita en v4. config.FromEnvironment() debe estar en la cadena de opciones. El SDK ya no lee variables de entorno de forma implícita durante la construcción.
Para el recorrido completo de autenticación, consulta la guía de autenticación en el repositorio del SDK.

Multi-tenancy


El ámbito del tenant proviene de las claims de Access Manager o JWT usadas para obtener el token. El SDK aplica la identidad del tenant automáticamente a partir de esas claims. El lado del cliente no necesita configuración adicional. Para ejecutar llamadas bajo un ámbito de tenant diferente, usa un conjunto distinto de credenciales de Access Manager, o crea un segundo cliente con su propio contexto de token.

Listado e iteración


Cada endpoint de listado en v4 viene en tres variantes. Elige la que se ajuste a tu caso de uso. Son consistentes en todos los servicios.

Opciones de listado tipadas

Cada método de listado recibe una struct de opciones tipada que incorpora una de dos structs base, según cómo pagine el endpoint: Cada endpoint también expone una subestructura Filters tipada, con solo los campos que ese endpoint realmente admite. Establecer un campo en la forma incorrecta (por ejemplo, Page en un endpoint basado en cursor) falla en tiempo de compilación, no de forma silenciosa en tiempo de ejecución.

Itera cada elemento con ListAll

La forma más idiomática es un bucle range sobre cada elemento en todas las páginas. El SDK avanza los cursores y obtiene las páginas internamente.

Itera los sobres de página con ListPages

Cuando necesitas metadatos en el nivel de página (para checkpointing, procesamiento por lotes o detenerte a mitad de página), itera sobre ListXxxPages en su lugar. Cada entrada es un *ListResponse[T] con el bloque Pagination completo adjunto.
Consulta la guía de paginación en el repositorio del SDK para conocer la semántica de HasMore(), el manejo de NextCursor y la tabla de decisión entre página y cursor.

Manejo de errores


La mayoría de los errores que retorna la capa de servicios del SDK son *pkg/errors.Error con campos estructurados: Puedes ramificar la lógica con predicados tipados, recorrer los campos con errors.As, o usar el método canónico Retryable() para guiar la política de reintentos.

Ramifica la lógica con predicados tipados

El SDK incluye un conjunto completo de predicados Is* para que puedas identificar errores sin acceder a los internos:

Guía las decisiones de reintento con Retryable()

El método Error.Retryable() es la fuente canónica para la política de reintentos. Úsalo en lugar de construir tu propia clasificación.

Envuelve errores de transporte sin procesar

Si llamas a código HTTP de nivel más bajo fuera del SDK y quieres la misma forma de error estructurado, usa ClassifyTransportError:

Validación local: FieldErrors

La validación local de entradas expone *pkg/validation.FieldErrors, una colección estructurada de observaciones por campo generadas por el SDK antes de cualquier llamada HTTP. Usa errors.As para inspeccionarlas al validar la entrada del usuario o los builders.
Para el mapa completo de categorías, todos los códigos y la semántica de los límites de reintento, consulta la guía de manejo de errores en el repositorio del SDK.

Registro


En v4, *slog.Logger es la superficie canónica de logger. Conéctalo mediante midaz.WithLogger(...). El SDK es silencioso de forma predeterminada. Usa slog.DiscardHandler hasta que lo actives. Tú decides el handler, el nivel y el destino.
zap, zerolog y charmbracelet/log se integran como adaptadores slog.Handler. El SDK funciona con cualquier backend que hable slog.
La guía de registro tiene recetas de adaptadores para todas las bibliotecas de registro comunes.

Observabilidad


OpenTelemetry es de primera clase en v4. Un único proveedor de observabilidad te da spans, métricas y logs correlacionados con OTel mediante un solo punto de conexión. Configura la observabilidad pasando un proveedor completamente construido, o pasando opciones que el SDK ensambla por ti.

Conecta un proveedor

O pasa opciones en línea

El SDK emite un span HTTP por cada solicitud saliente, con la propagación correcta de traceparent de W3C. Los registros de log de negocio llevan solo IDs seguros, nunca payloads, nombres, direcciones o encabezados de autenticación. También puedes envolver un bloque de lógica de negocio en un span mediante Client.Trace:
WithObservabilityOptions y WithObservabilityProvider usan semántica de reemplazo, no de fusión. Cada llamada reemplaza cualquier proveedor instalado antes. Para partir de una base, incluye observability.WithDevelopmentDefaults u observability.WithProductionDefaults como primera opción en la cadena.
Consulta el ejemplo 10-observability-otel en el repositorio del SDK para ver los atributos de span, los nombres de métrica y la configuración del exportador.

Idempotencia


La idempotencia automática está activada de forma predeterminada en v4. El SDK emite un encabezado X-Idempotency: <uuid> en cada solicitud HTTP no segura (POST, PUT, PATCH, DELETE). Así, los reintentos ante fallos transitorios no crean recursos duplicados. Puedes sobrescribir la clave generada automáticamente en cada llamada cuando necesitas una clave estable proporcionada por quien llama. Esto es típico en pasos de saga, filas de outbox o envíos impulsados por la interfaz.

Define una clave estable por solicitud

Suprime la idempotencia para una llamada

Para endpoints administrativos poco frecuentes de tipo fire-and-forget, suprime el encabezado por solicitud:

Deshabilita de forma global

Si no quieres la idempotencia automática en ningún lugar, desactívala en el nivel del cliente:
También puedes deshabilitarla mediante la variable de entorno MIDAZ_IDEMPOTENCY=false cuando usas config.FromEnvironment().

Variables de entorno


Puedes configurar el SDK con variables de entorno en lugar de valores fijos en el código. La carga desde el entorno es explícita en v4. Pasa config.FromEnvironment() en tu cadena de opciones de configuración para activarla. Para la matriz completa de opciones de midaz, pkg/config y pkg/sdkctx, consulta la guía de configuración en el repositorio del SDK.

Proyectos de ejemplo


El SDK incluye un recorrido numerado por sus capacidades principales (ejemplos 01–10), además de un conjunto de ejemplos avanzados y de referencia. El conjunto numerado son tutoriales enfocados: cada uno enseña exactamente un concepto con el cuerpo más pequeño posible. Explóralos en el directorio de ejemplos en GitHub.
El repositorio también incluye ejemplos especializados y de referencia: concurrency, configuration, context, tracing, tracing-server, pkg-validation-demo, mass-demo-generator y workflow-with-entities. Cubren patrones avanzados (paralelismo acotado, propagación de contexto de OTel entre procesos, generación masiva de datos) para cuando ya superaste el conjunto enfocado.

Migración desde v2


v4 es una versión mayor de corte limpio, sin ventana de desuso. No hay una versión de transición, ni un shim // Deprecated:, ni un alias retrocompatible de la superficie anterior. Cambia tu import de /v2 a /v4 y revisa los cambios incompatibles a continuación. Los cambios más grandes que debes planear:
  • Ruta del módulo y nombre del paquete: github.com/LerianStudio/midaz-sdk-golang/v4 (antes /v2), paquete midaz (antes client).
  • Autenticación: WithAuthToken desapareció. Usa WithAccessManager para producción o WithAnonymous para stacks locales. Se requiere una fuente de autenticación en el momento de la construcción.
  • Acceso a servicios: c.Accounts.X (antes c.Entity.Accounts.X). El campo c.Entity todavía existe por compatibilidad, pero todos los ejemplos usan la forma corta.
  • Paginación: models.ListOptions y sus 30 setters fluidos desaparecieron. Usa las opciones tipadas por endpoint (models.AccountsListOpts, models.TransactionsListOpts, …) y los nuevos iteradores ListAll / ListPages.
  • Errores: *MidazError desapareció. Los errores de la capa de servicios ahora usan *pkg/errors.Error, con Retryable() como fuente oficial de reintentos. La validación local puede exponer *pkg/validation.FieldErrors.
  • Identidad del tenant: WithTenantID, la variable de entorno MIDAZ_TENANT_ID y el encabezado X-Tenant-ID desaparecieron. El ámbito del tenant fluye a través de las claims de Access Manager o JWT.
  • Registro: *slog.Logger reemplaza a la interfaz personalizada observability.Logger como superficie canónica. El SDK es silencioso de forma predeterminada.
Para conocer los cambios de autenticación en detalle, consulta la guía de autenticación en el repositorio del SDK. El directorio de ejemplos muestra la API v4 en la práctica.

Explora las API


Para más información sobre las API, consulta los siguientes enlaces:

Mapeo de la API externa

Mapeo de la API interna

Documentación de Godoc