Skip to main content
O Midaz SDK para Go é o cliente v4 idiomático para as APIs de Ledger financeiro do Midaz. Ele oferece acesso tipado a todos os serviços — Organizations, Ledgers, Accounts, Transactions e mais — com uma única superfície para autenticação, paginação, erros, logging e observabilidade. O SDK cuida do código repetitivo para que seu código fique focado na lógica de negócio.
Vindo da v2? A v4 é uma major version limpa, com breaking changes em autenticação, paginação, erros e acesso a serviços. Não há janela de depreciação — você troca seu import de /v2 para /v4 e migra ao mesmo tempo.Veja Migrando da v2 antes de atualizar.

Primeiros passos


Passo 1 – Instale o Go

Antes de usar o SDK, você deve instalar o Go na sua máquina. A v4 declara Go 1.26 no go.mod. A API pública também usa iter.Seq2 e log/slog.
2
Baixe o instalador para o seu sistema operacional (Windows, macOS ou Linux).

Passo 2 – Crie ou use um projeto Go existente

Crie um projeto Go: Para criar um projeto Go, use o seguinte comando:
Use um projeto Go existente: Se você está trabalhando em um projeto existente, certifique-se de que há um arquivo go.mod na raiz. Se não, execute o seguinte comando para criar um:

Passo 3 – Adicione o Midaz SDK

Dentro do diretório do seu projeto, execute o seguinte comando para baixar o SDK v4 e adicioná-lo aos seus arquivos go.mod e go.sum:
O caminho do módulo exige o sufixo /v4. Se você omitir, o Go vai resolver uma release antiga, anterior à v4, que não tem nenhuma das mudanças entregues nesta versão. Sempre importe github.com/LerianStudio/midaz-sdk-golang/v4.
Usando VS Code ou GoLand? Sua IDE pode executar go get automaticamente quando você importa um novo pacote.

Passo 4 – Importe o SDK

Crie ou abra um arquivo main.go e adicione o seguinte conteúdo. O exemplo abaixo cria um cliente contra seu stack Midaz local com autenticação anônima, lista organizações e cria uma nova.
O exemplo abaixo aponta para um stack Midaz local com auth desabilitada. Se você ainda não tem um rodando, veja Primeiros passos com o Midaz para subir um antes de executar o snippet.
Isso te dá acesso a:
  • O cliente Midaz para chamar todos os serviços da API.
  • Os data models embutidos (como CreateOrganizationInput).
  • Autenticação via Access Manager (produção) ou Anonymous (desenvolvimento local).
  • Um sistema de configuração tipado que falha rápido na construção do cliente.
Quer aprender mais sobre autenticação? Pule para a seção Autenticação para a configuração completa.

Passo 5 – Execute o projeto

Execute o seguinte comando:

Arquitetura do SDK


O Midaz SDK para Go é construído com clareza e previsibilidade. Todo serviço é acessado direto no cliente. Todo método de listagem segue o mesmo trio de assinaturas. Todo erro é estruturado. Toda opção falha rápido na construção.

Design em camadas

Os serviços são acessados direto no cliente — c.Accounts, c.Transactions, c.Organizations. Você pode ver um campo Entity embutido no autocomplete, mas código novo deve usar os campos de serviço diretos mostrados neste guia.
Quer mergulhar mais fundo? Confira o guia de arquitetura para a história completa por trás do rewrite.

Serviços

A camada Services é seu ponto de acesso a cada domínio do Midaz. Cada serviço cuida de uma família de recursos e entrega todos os métodos como parte de sua única interface — sem toggle UseAllAPIs(), sem etapa de registro de serviço. Todo serviço está pronto para uso no momento em que midaz.New() retorna.

Serviços disponíveis

Models

Os models refletem como o Midaz pensa em finanças, com cada tipo amarrado a um conceito de negócio do mundo real. Você vai usá-los em toda chamada de serviço — desde o onboarding de contas até o registro de transações multi-leg. Na v4, os tipos de model mais comuns são re-exportados no próprio pacote midaz. Isso significa que midaz.Account e models.Account são o mesmo tipo, e a maioria do código só precisa de um import.

Tipos de modelos comuns

Precisa de um builder, de uma struct de request interna ou de um tipo deprecado? Importe github.com/LerianStudio/midaz-sdk-golang/v4/models direto — todo tipo vive lá, e os aliases do midaz preservam a identidade dos tipos, então os dois caminhos de import interoperam sem fricção.

Pacotes utilitários

Dentro da pasta pkg do SDK, você encontra pacotes utilitários para desafios comuns de dev — tratamento de config, políticas de retry e primitivas de segurança. Eles se dividem em dois grupos. Os pacotes core sustentam preocupações transversais do SDK. Os pacotes helpers oferecem utilitários específicos de domínio ou de baixo nível.

Pacotes core

Pacotes helpers

O pacote pkg/access-manager da v2 virou pkg/auth (assim o nome do diretório bate com o nome do pacote). O pacote pkg/pagination da v2 foi removido — sua superfície hoje vive em models e em cada serviço.

Autenticação


Na v4, o SDK exige exatamente uma fonte de autenticação no momento da construção. Chamar midaz.New(...) sem nenhuma retorna um erro de configuração tipado — chega de cascatas silenciosas de 401 na primeira chamada de API. Você tem duas escolhas:
  • midaz.WithAccessManager(...) — OAuth no formato de produção via Lerian Access Manager. Recomendado para qualquer stack não-local.
  • midaz.WithAnonymous() — opt-out total de autenticação. Apropriado apenas para um stack Midaz local com auth desabilitada.
As duas opções são mutuamente exclusivas.

Produção: Access Manager

Encaixe suas credenciais do Access Manager em midaz.WithAccessManager. O SDK busca um token inicial logo na construção, então erros de configuração aparecem como erros de configuração e não como uma cascata de 401.
Substitua os valores no bloco // Configure Access Manager por suas próprias credenciais antes de executar.
O SDK pede um token ao seu Access Manager, anexa em toda chamada de API e renova automaticamente quando ele expira.

Desenvolvimento local: Anonymous

Para um stack Midaz local com auth desabilitada, faça o opt-out de forma explícita:

Configure via variáveis de ambiente

Você também pode apontar o SDK para o seu Access Manager via variáveis de ambiente. Exporte-as no seu shell ou no seu gerenciador de processos:
config.FromEnvironment() lê o ambiente do processo, não um arquivo .env. Se você mantém variáveis em um arquivo .env durante o desenvolvimento, carregue-as com uma biblioteca como godotenv antes de chamar config.NewConfig(config.FromEnvironment()).
Depois, faça o opt-in para o carregamento via env no momento de configurar:
O carregamento via env é explícito na v4 — config.FromEnvironment() precisa estar na cadeia de opções. O SDK não lê mais env vars de forma implícita durante a construção.
Quer o passo a passo completo de auth? Confira o Guia de autenticação no repositório do SDK.

Multi-tenancy


O escopo de tenant vem dos claims do Access Manager / JWT usados para obter o token. O SDK aplica a identidade de tenant automaticamente a partir desses claims — nenhuma configuração extra no client. Para rodar chamadas em outro escopo de tenant, use um conjunto separado de credenciais de Access Manager — ou construa um segundo cliente com seu próprio context de token.

Listagem e iteração


Todo endpoint de listagem na v4 vem em três formatos. Escolha o que casa com seu caso de uso — eles são consistentes em todos os serviços.

Opções de listagem tipadas

Cada método de listagem recebe uma struct de opts tipada que embute uma de duas structs base, dependendo de como o endpoint pagina: Cada endpoint também expõe uma sub-struct Filters tipada com apenas os campos que aquele endpoint realmente honra. Setar um campo no formato errado — por exemplo, Page em um endpoint cursor-based — falha em tempo de compilação, não silenciosamente em runtime.

Itere todos os itens com ListAll

O formato mais idiomático: um range sobre todo item de toda page. O SDK avança cursors e busca pages internamente.

Itere envelopes de page com ListPages

Quando você precisa de metadados de page — para checkpointing, batching ou para parar no meio de uma page —, itere por ListXxxPages. Cada entrada é um *ListResponse[T] com o bloco Pagination completo anexado.
Veja o guia de Paginação no repositório do SDK para a semântica de HasMore(), o tratamento de NextCursor e a tabela de decisão page-vs-cursor.

Tratamento de erros


A maioria dos erros retornados pela camada de serviço do SDK é *pkg/errors.Error com campos estruturados: Você pode ramificar com predicados tipados, percorrer os campos com errors.As, ou usar o método canônico Retryable() para guiar sua política de retry.

Ramifique com predicados tipados

O SDK traz um conjunto completo de predicados Is* para você casar erros sem cutucar internals:

Guie decisões de retry com Retryable()

O método Error.Retryable() é a fonte canônica para política de retry. Use-o no lugar de construir sua própria classificação.

Embrulhe erros de transporte raw

Se você está chamando código HTTP de baixo nível fora do SDK e quer o mesmo formato de erro estruturado, use ClassifyTransportError:

Validação local: FieldErrors

A validação local de input expõe *pkg/validation.FieldErrors — uma coleção estruturada de reclamações por campo emitidas pelo SDK antes de qualquer chamada HTTP. Use errors.As para inspecioná-las quando estiver validando input do usuário ou builders.
Quer mergulhar mais fundo? Confira o guia de Tratamento de erros no repositório do SDK para o mapa completo de categorias, todos os códigos e a semântica das fronteiras de retry.

Logging


Na v4, *slog.Logger é a superfície canônica de logger. Conecte-o via midaz.WithLogger(...). O SDK é silencioso por padrão — ele usa slog.DiscardHandler até você fazer o opt-in. Isso significa que você não vai ver linhas de log surpresa no seu stdout, e nem precisa brigar com o SDK por formato de log. Você decide o handler, o nível e o destino.
Precisa de zap, zerolog ou charmbracelet/log? Todos integram como adapters de slog.Handler — o SDK não se importa qual backend produz os records, só que ele fale slog.
Conectando zap, zerolog ou outro backend? O guia de Logging traz receitas de adapter para todas as bibliotecas de logging comuns.

Observabilidade


OpenTelemetry é first-class na v4. Um único provider de observabilidade te dá spans, métricas e logs correlacionados via OTel por meio de um único ponto de wiring. Configure observabilidade passando um provider já construído, ou passando opções que o SDK monta para você.

Conecte um provider

Ou passe opções inline

O SDK emite um span HTTP por request outbound com propagação correta de traceparent W3C. Os records de log de negócio carregam apenas IDs seguros — nunca payloads, nomes, endereços ou auth headers. Você também pode embrulhar um bloco de lógica de negócio em um span via Client.Trace:
WithObservabilityOptions e WithObservabilityProvider usam semântica de substituição, não de merge. Cada chamada substitui qualquer provider previamente instalado. Para começar a partir de uma baseline, inclua observability.WithDevelopmentDefaults ou observability.WithProductionDefaults como a primeira opção na cadeia.
Quer mergulhar mais fundo? Veja o exemplo 10-observability-otel no repositório do SDK para os atributos de span, nomes de métricas e configuração de exporter.

Idempotência


A auto-idempotency está ligada por padrão na v4. O SDK emite um header X-Idempotency: <uuid> em todo request HTTP unsafe (POST, PUT, PATCH, DELETE). Retries em falhas transientes não criam recursos em duplicidade. Você pode sobrescrever a chave auto-gerada por chamada quando precisar de uma chave estável fornecida pelo caller — típico em passos de saga, linhas de outbox ou submissões dirigidas pela UI.

Defina uma chave estável por request

Suprima a idempotency em uma chamada

Para os raros endpoints administrativos do tipo fire-and-forget, suprima o header por request:

Desative globalmente

Se você não quer auto-idempotency em lugar nenhum, desligue no nível do cliente:
Você também pode desativar via a variável de ambiente MIDAZ_IDEMPOTENCY=false quando estiver usando config.FromEnvironment().

Variáveis de ambiente


Você pode configurar o SDK com variáveis de ambiente em vez de valores hardcoded. O carregamento via env é explícito na v4 — passe config.FromEnvironment() na sua cadeia de opções de config para fazer o opt-in. Para a matriz completa de opções entre midaz, pkg/config e pkg/sdkctx, consulte o guia de Configuração no repositório do SDK.

Projetos de exemplo


O SDK vem com um tour numerado das suas capacidades core (exemplos 01–10) mais um conjunto de exemplos avançados e de referência. O conjunto numerado é de tutoriais focados: cada um ensina exatamente um conceito com o menor corpo possível. Navegue por eles no diretório de exemplos no GitHub.
O repositório também inclui exemplos especializados e de referência — concurrency, configuration, context, tracing, tracing-server, pkg-validation-demo, mass-demo-generator e workflow-with-entities. Eles cobrem padrões avançados (paralelismo limitado, propagação de context OTel entre processos, geração massiva de dados) para quando você passou do conjunto focado.

Migrando da v2


A v4 é uma major version de corte limpo, sem janela de depreciação. Não há release transicional, não há shim // Deprecated:, não há alias retrocompatível da superfície antiga. Troque seu import de /v2 para /v4 e percorra as breaking changes abaixo. As maiores mudanças para planejar:
  • Caminho do módulo e nome do pacote: github.com/LerianStudio/midaz-sdk-golang/v4 (era /v2), pacote midaz (era client).
  • Autenticação: WithAuthToken foi embora. Use WithAccessManager para produção ou WithAnonymous para stacks locais. Uma fonte de auth é obrigatória na construção.
  • Acesso a serviços: c.Accounts.X (era c.Entity.Accounts.X). O campo c.Entity ainda existe por compatibilidade, mas todo exemplo usa a forma curta.
  • Paginação: models.ListOptions e seus 30 fluent setters foram embora. Use as opts tipadas por endpoint (models.AccountsListOpts, models.TransactionsListOpts, …) e os novos iteradores ListAll / ListPages.
  • Erros: *MidazError foi embora. Erros da camada de serviço agora usam *pkg/errors.Error com Retryable() como fonte oficial de retry. Validação local pode expor *pkg/validation.FieldErrors.
  • Identidade de tenant: WithTenantID, a variável de ambiente MIDAZ_TENANT_ID e o header X-Tenant-ID foram embora. O escopo de tenant flui pelos claims do Access Manager / JWT.
  • Logging: *slog.Logger substitui a interface dedicada observability.Logger como superfície canônica. O SDK é silencioso por padrão.
Para os detalhes das mudanças de autenticação, veja o Guia de autenticação no repositório do SDK. O diretório de exemplos mostra a API v4 na prática.

Explore as APIs


Para mais informações sobre as APIs, consulte os links a seguir:

Mapeamento da API externa

Mapeamento da API interna

Documentação Godoc