> ## Documentation Index > Fetch the complete documentation index at: https://developers.sults.com.br/llms.txt > Use this file to discover all available pages before exploring further. # Autenticação na API v1 do SULTS > Como a API do SULTS autentica cada requisição: geração de tokens, v1 vs v2, guarda segura em produção e rotação API v1 Toda chamada à API do SULTS é autenticada por um **token** enviado no cabeçalho `Authorization`. A API é stateless: não existe sessão nem login; o token é validado a cada requisição. | Cabeçalho | Valor | Obrigatório | | - | - | - | | `Authorization` | O token v1 gerado no SULTS, **puro, sem o prefixo `Bearer`** | Sim, em todas as requisições | | `Content-Type` | `application/json` | Nas requisições com corpo (POST e PUT) | A API **não usa** o esquema `Bearer`: envie `Authorization: SEU_TOKEN`, e não `Authorization: Bearer SEU_TOKEN`. Esse prefixo é uma das causas mais comuns de 401 em quem vem de outras APIs. ## Gere o seu token O token é criado dentro da própria plataforma, por um usuário **administrador**: 1. Acesse `https://suamarca.sults.com.br` e faça login. 2. No painel inicial, clique no ícone **Segurança**. 3. No menu lateral esquerdo, clique em **API**. 4. Abra **Gestão de Tokens v1** e clique em **Criar Token**. 5. Dê um nome ao token e crie. **Copie o código gerado** e guarde em local seguro. Tela de Segurança > API no SULTS, com os cards de Gestão de Tokens v1 e v2 Se preferir acompanhar em vídeo, veja o passo a passo na [Central de Ajuda](https://ajuda.sults.com.br/sults/como-gerar-token-de-integracao/). ## Tokens v1 vs v2 A tela de API tem duas gestões de token, e a diferença importa: | | Gestão de Tokens v1 | Gestão de Tokens v2 | | - | - | - | | Funciona nesta API (v1) | Sim | **Não** | | Uso | Todos os endpoints desta documentação | Nova geração da API do SULTS | **Tokens v2 não funcionam nos endpoints da API v1.** Se as suas chamadas estão sendo recusadas com um token recém-criado, confira em qual gestão ele foi gerado. ## O que o token pode fazer O token da v1 dá acesso a **todos os endpoints** da API, incluindo os 7 de escrita em Chamados, Compras e Expansão. Não existe permissão ou escopo por token nesta versão: qualquer token válido lê e escreve tudo o que a API expõe. Considere isso ao decidir quem guarda cada token. ## Um token por integração Crie um token para cada sistema que se conecta ao SULTS e nomeie pelo sistema (por exemplo, `ERP Financeiro`, `BI Comercial`). Isso permite revogar um acesso sem derrubar os demais e facilita identificar a origem de cada chamada. Na mesma tela de API, o **Log de Eventos** ajuda a acompanhar o uso. ## Guarda do token em produção Trate o token como uma senha de administrador: * **Servidor, nunca navegador ou app.** Mesmo com CORS habilitado na API, chamadas feitas do frontend expõem o token a qualquer visitante. Crie um endpoint no seu backend que repassa as chamadas ao SULTS. * **Variáveis de ambiente ou cofre de segredos**, nunca no código-fonte, em repositórios (mesmo privados), em URLs ou em logs. * **Rotação sem downtime**: crie o token novo, publique a sua aplicação usando o novo, e só então exclua o antigo na Gestão de Tokens. * **Se um token vazar**: exclua-o imediatamente na Gestão de Tokens, gere outro e revise o Log de Eventos em busca de uso indevido. ## Problemas de autenticação Chamada recusada? Confira, nesta ordem: o token foi copiado por completo; o cabeçalho tem o nome exato `Authorization`; o valor é **apenas o token**, sem o prefixo `Bearer`; o token é **v1**. Persistindo a falha, o corpo da resposta traz os detalhes: veja o guia de [Erros](/v1/erros). ## Próximos passos Use o seu token na primeira chamada, com exemplos em 5 linguagens. Datas, máscaras, paginação e as URLs base de cada módulo. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.