clientId e clientSecret).POST /v1/token.Authorization: Bearer.clientId / clientSecret, específico para cada ambiente (produção ou sandbox). Nos próximos passos você verá como trocar essas credenciais por um token — o guia de Autenticação traz o detalhe de como obter suas credenciais e como funciona o fluxo por trás do token.POST /v1/token. A resposta contém um access_token válido por 15 minutos, que você usará nas chamadas seguintes.{
"access_token": "eyJhbGciOiJFUzI1NiI..."
}POST /v1/token é o ponto de entrada do fluxo e não exige permissão. Todos os demais endpoints exigem o token obtido aqui. Detalhes do modelo de autenticaç ão e das permissões estão em Autenticação.access_token no header Authorization: Bearer <access_token>. O exemplo abaixo cria um lead — name, email, phone e seller são obrigatórios:{
"leadId": "ld_123"
}403, é porque seu token não tem a permissão necessária para essa operação — veja Autenticação para entender como as permissões funcionam./v1/...). Ainda não há um changelog público nem uma política formal de depreciação documentada — mudanças que quebrem compatibilidade seriam comunicadas por outro canal, a definir.