client_secret. Esta é uma integração server-side: todas as trocas de token precisam acontecer no seu back-end. O client_secret nunca pode ser exposto em código no browser, binários de app mobile ou qualquer ambiente que o usuário final possa inspecionar.
Antes de continuar, você precisa de um client_id e client_secret. Veja Registre seu aplicativo.
Como funciona
Redirecionar o usuário para o endpoint de autorização
Seu servidor constrói a URL de autorização e redireciona o browser do usuário para ela.
Usuário faz login e aprova
O usuário seleciona um workspace e visualiza os escopos solicitados na tela de consentimento da
Vendaze. Ele pode apenas aprovar ou negar o acesso completo, sem opção de selecionar escopos
individualmente.
Receber o código de autorização
A Vendaze redireciona o browser de volta para sua
redirect_uri com um code de curta duração.Trocar o code pelos tokens
Seu servidor troca o code por um
access_token e refresh_token via requisição back-end.Passo 1 - Redirecionar o usuário
Construa a URL de autorização e redirecione o browser do usuário para ela. Isso deve ser uma navegação de browser, não uma requisição HTTP server-side. Não usefetch, axios, curl ou qualquer cliente HTTP para chamar este endpoint. O usuário precisa ser redirecionado para que possa fazer login e aprovar o acesso na tela de consentimento da Vendaze.
| Parâmetro | Obrigatório | Descrição |
|---|---|---|
client_id | Sim | O client ID do seu aplicativo. |
redirect_uri | Sim | Deve corresponder exatamente a uma URI registrada. |
response_type | Sim | Deve ser code. |
state | Não | String aleatória que você gera. Retornada sem alteração. Fortemente recomendada para proteção contra CSRF. |
Passo 2 - Usuário autoriza
O usuário seleciona o workspace e visualiza os escopos solicitados na tela de consentimento da Vendaze. Ele pode apenas aprovar ou negar o acesso completo, sem opção de selecionar escopos individualmente. Nenhuma ação necessária do seu lado durante este passo.Passo 3 - Receber o callback
Após aprovar, o usuário é redirecionado para suaredirect_uri:
state bate com o que você armazenou e troque o code pelos tokens. Se o usuário recusar a autorização:
error e exiba uma mensagem adequada ao usuário.
Passo 4 - Trocar o code pelos tokens
Esta requisição deve ser feita pelo seu servidor, nunca pelo browser.| Campo | Descrição |
|---|---|
access_token | Use em toda requisição à API. Expira em 1 hora. |
refresh_token | Usado para renovar o access token. Válido por 60 dias se utilizado regularmente. |
token_type | Sempre Bearer. |
expires_in | Segundos até o access token expirar. Sempre 3600. |
workspace_slug | Slug do workspace autorizado pelo usuário. Use para identificar qual conta está conectada no seu app. |
Armazenamento de tokens
Armazene os dois tokens com segurança no servidor. As seguintes práticas se aplicam:access_token: curta duração (1 hora). Armazene em memória ou cache rápido. Nunca em localStorage ou cookies acessíveis ao JavaScript.refresh_token: longa duração (60 dias). Armazene criptografado no banco de dados, associado ao usuário e workspace. É a credencial que permite manter o acesso sem interação do usuário.- Nunca logue nenhum dos tokens. Nunca os inclua em URLs ou query strings.
- Nunca os exponha em respostas da API para o seu próprio front-end. O front-end deve chamar seu back-end, que chama a Vendaze.
Passo 5 - Fazer requisições à API
Inclua oaccess_token em toda requisição como Bearer token:
Passo 6 - Renovar o access token
Access tokens expiram em 1 hora. Renove usando o refresh token antes da expiração, ou reativamente quando receber o errotoken_expired.
refresh_token é emitido a cada renovação e o anterior é imediatamente invalidado.
Refresh tokens expiram se ficarem sem uso por 60 dias. A cada renovação, a janela de 60 dias é
reiniciada. Se expirar, o usuário precisa passar pelo fluxo completo de autorização novamente.
Revogar acesso
Para desconectar um workspace do seu aplicativo, revogue o access token:Próximo: Faça sua primeira requisição para usar seu access token em uma chamada real à API.