Permissões

O bitERP usa um modelo de permissões granular por recurso e ação. Cada API Key ou usuário OAuth tem permissões específicas que controlam o que pode ser acessado.

Modelo de permissões

Cada permissão é composta por:

Campo	Descrição	Exemplo
`resource_code`	Código do recurso	`products`, `customers`
`can_create`	Permissão para criar	`true` / `false`
`can_read`	Permissão para listar e buscar	`true` / `false`
`can_update`	Permissão para atualizar	`true` / `false`
`can_delete`	Permissão para remover	`true` / `false`

Como funciona

Com API Keys

As permissões são definidas na criação da API Key e são imutáveis — não podem ser alteradas depois. Para mudar permissões, crie uma nova key.

Exemplo: uma API Key com permissão products:read e products:create pode listar e criar produtos, mas não pode atualizar ou deletar.

Com OAuth2

O comportamento depende da role do usuário:

Role	Comportamento
`admin`	Acesso completo (bypass de permissões)
`member`	Permissões granulares por recurso, idênticas ao modelo de API Keys

Respostas de erro

Quando uma operação é negada por falta de permissão, a API retorna:

{
    "statusCode": 403,
    "message": "Forbidden",
    "error": "You do not have permission to perform this action"
}

Recursos disponíveis

Os códigos de recurso atualmente suportados:

Código	Recurso
`products`	Produtos
`customers`	Clientes
`suppliers`	Fornecedores
`financial_accounts`	Contas financeiras
`financial_transactions`	Transações financeiras
`receivables`	Contas a receber
`payables`	Contas a pagar

Boas práticas

Princípio do menor privilégio: conceda apenas as permissões necessárias para a integração
Keys separadas por integração: crie uma API Key diferente para cada sistema que integra com o bitERP
Expiração: configure expires_at sempre que possível
Revogação: revogue keys que não são mais necessárias