Skip to main content
A API REST aceita um personal access token como credencial Bearer em cada requisição. O servidor MCP e a API REST também compartilham o mesmo servidor de autorização OAuth 2.0, montado em {origin}/oauth, para clientes que agem em nome de um usuário.

​
Personal access tokens

Para scripts, serviços de backend e qualquer outra chamada direta à API REST, use um personal access token (PAT):
Crie um pelo dashboard: Configurações do usuário → API Keys. O token é exibido apenas uma vez, no momento da criação — guarde-o em um gerenciador de segredos ou variável de ambiente, nunca no código-fonte. Personal access tokens estão disponíveis nos planos que incluem a API REST; revogue um token na mesma tela a qualquer momento, com efeito imediato.

​
OAuth 2.0 (aplicações de terceiros)

Use o fluxo authorization-code + PKCE para clientes que agem em nome de um usuário.

​
Descoberta

Os clientes descobrem o servidor de autorização por meio de documentos de metadados padrão: O endpoint MCP retorna 401 com um header WWW-Authenticate, então clientes MCP compatíveis com a especificação inicializam o fluxo OAuth automaticamente.

​
Fluxo

  1. GET /oauth/authorize com response_type=code, client_id, redirect_uri, code_challenge, code_challenge_method=S256 e state.
  2. O usuário se autentica e aprova; a iZap redireciona de volta com code.
  3. POST /oauth/token com grant_type=authorization_code, code, redirect_uri e code_verifier → retorna um access_token (JWT) e um refresh_token.
Clientes públicos podem se autorregistrar via POST /oauth/register. Renove um token expirado com grant_type=refresh_token.

​
Notas sobre tokens

  • Todo token — personal access token ou token de acesso OAuth — é um segredo. Leia-o a partir de uma variável de ambiente ou gerenciador de segredos, nunca o deixe fixo no código.
  • Um personal access token não expira sozinho; ele é válido até que você o revogue pelo dashboard.
  • Tokens de acesso OAuth expiram. Use o refresh grant quando uma requisição retornar 401.