Permissões e tokens

O token faz o que a pessoa dona dele pode fazer no escritório do caminho, nunca mais do que isso. As permissões são lidas a cada requisição, em cada escritório: o que muda para a pessoa muda para o token.

• Cada endpoint mostra a Permissão exigida. Sem ela, 403 SEM_PERMISSAO.
• Quem só alcança um departamento recebe 404 NAO_ENCONTRADO no que é de outro.
• Token só de leitura recebe 403 TOKEN_SO_LEITURA em qualquer escrita. Na API, a validação vem antes: corpo inválido pode dar 400 em vez do 403. No MCP, as ferramentas de escrita nem aparecem.
• Toda alteração entra nos logs do escritório em nome da pessoa, com o nome do token.

Datas que dependem de aprovação

Sem a permissão "Aprovar mudança de data" (de prazos ou de trabalhos), mudar a data de um trabalho ou prazo cria uma solicitação. Os outros campos do pedido são gravados, a data antiga continua valendo e a resposta é 202:

{
  "pendente": true,
  "solicitacaoId": "0190a000-0000-7000-8000-000000000003"
}

Revogar e bloquear

Em Meus tokens de API, no menu do usuário, a pessoa vê em que escritórios cada token vale e revoga os próprios tokens: revogado, ele para em todos. Quem administra a API de um escritório não revoga o token de outra pessoa, mas pode bloqueá-lo em Administração: o bloqueio vale só naquele escritório.

O que nunca sai pela API

Nem pela API, nem pelo MCP, com nenhuma permissão:

• senhas de clientes, inclusive campos personalizados do tipo senha;
• o valor dos tokens;
• a administração de usuários, cargos, times e permissões;
• LGPD;
• Plataforma;
• importação;
• configuração de integrações.

O que sai sobre pessoas

O identificador e o nome dos colegas ativos, para escolher responsáveis (listar_membros), e os dados da própria pessoa dona do token, como e-mail e os escritórios em que o token vale (meus_escritorios).

A referência lista tudo o que existe.