> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # Parceiros > Dê a cada um dos seus clientes credenciais próprias e limite o que ele pode fazer, onde, de quais endereços e por quanto tempo. Esta funcionalidade está disponível apenas em Staging para testes e ainda não está disponível em Produção. Um parceiro é um dos seus próprios clientes que chama a sua plataforma Lerian pelos sistemas dele. O Access Manager permite dar a cada parceiro credenciais próprias. Você decide o que o parceiro pode fazer, em qual parte dos seus dados, de quais endereços de rede e por quanto tempo. Pense em um prédio com muitas salas. Você é o dono e tem todas as chaves. Um parceiro recebe um crachá que abre só as portas que você escolhe, funciona só no horário que você define e para de funcionar no momento em que você o cancela. ## Por que segregar o acesso *** Quando vários clientes chamam a sua plataforma, uma credencial compartilhada dá a cada um deles o acesso de todos. Os parceiros trocam isso por um conjunto de limites para cada cliente: * **Menor privilégio.** Cada parceiro recebe só as ações e os dados de que precisa, e nada acima do que a sua própria equipe pode fazer. * **Credenciais por parceiro.** Cada parceiro tem as próprias credenciais. Você pode revogar um parceiro sem mexer nos outros. * **Revogação imediata.** Suspender um parceiro, ou chegar ao fim da janela de validade dele, recusa a próxima requisição dele, mesmo com um token que ele já tem. * **Restrição de rede.** Um parceiro só pode chamar dos endereços que você lista para ele. * **Janelas de validade.** O acesso pode começar e terminar nas datas que você escolhe. Um piloto que termina em uma data não precisa de lembrete para ser desligado. * **Responsabilidade clara.** Cada requisição leva a credencial do próprio parceiro, então cada ação aponta para um único parceiro. ## Os blocos de construção *** Um tenant contém organizações, e uma organização contém ledgers. Um parceiro é um registro do tenant, e as linhas depois dele descrevem o que um parceiro recebe. | Conceito | O que é | Exemplo | | - | - | - | | **Tenant** | O seu ambiente na plataforma Lerian. Os seus usuários, aplicações e parceiros ficam dentro dele. | Um tenant para staging e outro para produção. | | **Organização do Midaz** | Uma empresa ou unidade de negócio dentro do seu tenant. Um tenant pode ter várias organizações. | "Organização Norte" e "Organização Sul". | | **Ledger** | Um conjunto de livros dentro de uma organização do Midaz. Uma organização pode ter vários ledgers. | "Ledger N1" e "Ledger N2" dentro da Organização Norte. | | **Parceiro** | Um registro dentro do seu tenant que representa um dos seus próprios clientes. Um parceiro não é um tenant. | "Parceiro A". | | **Aplicação do parceiro** | Uma credencial máquina a máquina (um client ID e um client secret) que pertence a um parceiro. Um parceiro pode ter várias. | Uma aplicação para o Midaz e outra para o Tracer. | | **Permissões** | **O que** o parceiro pode fazer: um produto, os recursos dele e as ações sobre eles. | Midaz: `accounts` e `transactions`, com `get` e `post`. | | **Escopo** | **Onde** o parceiro pode fazer: qual organização, quais ledgers, quais contas. Cada produto publica as restrições que aceita. | Só a Organização Norte, só o Ledger N1. | | **Teto** | O máximo que você pode dar a um parceiro em um produto: o que o papel de editor do produto tem no seu tenant. | Se o seu tenant não pode excluir contas, nenhum parceiro pode. | | **Lista de IPs permitidos do parceiro** | Os endereços de rede de onde as credenciais do parceiro podem chamar. | Só `203.0.113.10`. | | **Janela de validade e estado** | Quando as credenciais do parceiro funcionam (`validFrom` e `validUntil`) e se o parceiro está `active` ou `suspended`. | Válido por 90 dias, depois recusado. | ## Como as peças se encaixam *** O tenant é uma fronteira rígida. Os dados do seu tenant de staging nunca se misturam com os dados do seu tenant de produção. Dentro de um tenant, organizações e ledgers separam os seus dados de forma **lógica**: o Access Manager usa o escopo de cada parceiro para manter cada parceiro dentro da própria parte. * **Tenant: Produção.** O seu tenant de staging é outro, separado. * **Organização Norte** * **Ledger N1.** O Parceiro A escreve contas e transações aqui. * **Ledger N2** * **Contas 1 e 2.** O Parceiro C lê só estas duas contas. * **Organização Sul.** O Parceiro B lê a organização inteira, por 90 dias. * **Ledger S1** * **Ledger S2** Os três parceiros ficam no mesmo tenant. Nenhum deles vê a parte de outro. ## Exemplo: três parceiros em um tenant *** A sua empresa usa um tenant por ambiente. O tenant de produção tem duas organizações do Midaz, Norte e Sul. Três dos seus clientes precisam de acesso à API. ### Parceiro A: escreve em um ledger, de um endereço | Configuração | Valor | | - | - | | Permissões | Midaz: `accounts` com `get`, `post`, `patch`; `transactions` com `get`, `post` | | Escopo | Organização Norte, Ledger N1 | | Lista de IPs permitidos | Lista própria: `203.0.113.10/32` | | Validade | Sem limite de tempo | | Requisição | Resultado | | - | - | | Criar uma transação no Ledger N1, a partir de `203.0.113.10` | Permitida. | | Listar as contas do Ledger N1 | Permitida. | | Listar as contas do Ledger N2 | Recusada com `403`. O Ledger N2 está fora do escopo dele. | | Excluir uma conta no Ledger N1 | Recusada com `403`. `delete` não está nas permissões dele. | | Qualquer requisição de outro endereço | Recusada com `403` e código `AUT-0021`. | Você também não pode dar ao Parceiro A o direito de criar ledgers. Criar um ledger atua sobre a organização inteira, que é mais amplo que um ledger. O Access Manager recusa essa alteração com `IDE-1056`, e o Console mostra a linha como "Fora do escopo". ### Parceiro B: lê uma organização inteira por 90 dias | Configuração | Valor | | - | - | | Permissões | Midaz: `ledgers`, `accounts`, `balances`, `transactions`, todos com `get` | | Escopo | Organização Sul | | Lista de IPs permitidos | Usa a lista do seu tenant | | Validade | `validFrom` `2026-11-01T00:00:00Z`, `validUntil` `2027-01-30T23:59:59Z` | | Requisição | Resultado | | - | - | | Ler os saldos de qualquer ledger da Organização Sul, dentro da janela | Permitida. | | Criar uma transação na Organização Sul | Recusada com `403`. Ele só pode ler. | | Ler qualquer coisa da Organização Norte | Recusada com `403`. A Organização Norte está fora do escopo dele. | | Qualquer requisição antes de `2026-11-01T00:00:00Z` ou depois de `2027-01-30T23:59:59Z` | Recusada com `401` e código `AUT-1010`. Um token novo é recusado com o mesmo código. | ### Parceiro C: lê duas contas e depois é suspenso | Configuração | Valor | | - | - | | Permissões | Midaz: `accounts`, `balances`, `transactions`, todos com `get` | | Escopo | Organização Norte, Ledger N2, dois IDs de conta | | Lista de IPs permitidos | Lista própria: `198.51.100.0/24` | | Validade | Sem limite de tempo | | Requisição | Resultado | | - | - | | Ler os saldos e as transações das duas contas dele | Permitida. Uma restrição em uma conta também cobre os saldos, as transações e as operações dessa conta. | | Ler uma terceira conta no Ledger N2 | Recusada com `403`. | | Listar todas as contas do Ledger N2 | Recusada com `403`. Depois de restringir um tipo por ID, o parceiro não consegue listar nem criar itens desse tipo. | | Qualquer requisição depois que você suspende o Parceiro C | Recusada com `401` e código `AUT-1009`, também com um token emitido antes da suspensão. Quando você o reativa, as mesmas credenciais voltam a funcionar. | ## Como uma requisição é decidida *** As verificações abaixo rodam em cada requisição que a credencial de um parceiro envia a um produto. Elas rodam nesta ordem, e a primeira que falha para a requisição. 1. **Token.** O sistema do parceiro troca o client ID e o client secret por um token de acesso e envia o token com a requisição. 2. **Parceiro.** O Access Manager encontra o parceiro a quem a credencial pertence. 3. **Endereço de rede.** O Access Manager compara o endereço de quem chama com a lista própria do parceiro. Um parceiro sem lista própria usa a lista do seu tenant. Uma recusa retorna `403` com `AUT-0021`. 4. **Estado e validade.** Um parceiro suspenso, ou fora da janela de validade, é recusado com `401`: `AUT-1009` para suspenso, `AUT-1010` para fora da janela. 5. **Permissões.** O produto, o recurso e a ação precisam estar nas permissões do parceiro. Uma recusa retorna `403`. 6. **Escopo.** A organização, o ledger, a conta ou outro item que a requisição nomeia precisa estar dentro do escopo do parceiro. Uma recusa retorna `403`. 7. Se todas as verificações passam, o produto executa a requisição. O produto não diz a quem chama se foram as permissões ou o escopo que recusaram a requisição. Os dois retornam o mesmo `403`, então um parceiro não consegue usar as recusas para descobrir quais itens existem fora do escopo dele. ## O que você precisa saber *** * **Permissões e escopo precisam casar.** Um parceiro alcança só o que os dois permitem. Permissões sem escopo em um produto com restrição obrigatória não podem ser salvas. * **A suspensão e o fim da janela de validade valem na hora.** A próxima requisição do parceiro é recusada, mesmo com um token que ele já tem. Um parceiro suspenso também não consegue tokens novos. * **Qualquer outra alteração vale a partir da próxima requisição.** Isso inclui permissões novas, um escopo mais restrito e uma nova lista de IPs permitidos. * **Um parceiro nunca recebe mais do que o seu tenant tem.** O teto é o que o papel de editor do produto tem no seu tenant. Se esse papel perder uma permissão depois, o parceiro também a perde. * **O Access Manager não confere se os IDs do escopo existem no produto.** Ele guarda os IDs que você informa. Copie-os da própria API ou do Console do produto. * **Um produto mostrado como "ainda não está preparado para parceiros" ainda não publicou a lista de restrições dele.** Você não pode dar a um parceiro acesso a esse produto até que ele publique. * **Uma requisição que deixa de fora um item que o escopo restringe é recusada.** Por exemplo, um parceiro restrito a alguns ledgers não consegue listar todos os ledgers da organização. * **Um parceiro com aplicações não pode ser excluído.** Exclua as aplicações dele antes. Para pausar um parceiro, suspenda-o. A suspensão é reversível; a exclusão não. * **A lista de IPs permitidos própria de um parceiro substitui a lista do seu tenant.** Ela não se soma a ela. Um endereço que está só na lista do seu tenant não serve para esse parceiro. A lista do parceiro vale mesmo quando a lista do seu tenant está desligada. ## Produtos que aceitam parceiros *** Cada produto declara, no manifesto de permissões dele, quais restrições aceita: por exemplo organização, ledger, conta, portfólio ou segmento. Hoje o Midaz (o ledger) e o Tracer aceitam parceiros. O Midaz exige uma organização para cada parceiro e aceita restrições opcionais em ledgers, contas, aliases de conta, ativos, portfólios, segmentos, holders e outros itens. O Tracer aceita restrições opcionais em regras, limites, validações de transação, contas, portfólios, segmentos e merchants. ## Próximos passos *** Crie um parceiro passo a passo, emita as credenciais dele, suspenda-o ou exclua-o. As operações de parceiro, os campos, exemplos e códigos de erro. A lista do tenant que um parceiro sem lista própria usa. Todos os códigos que o Access Manager pode retornar. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.