Skip to main content
Este guia leva você do início até uma chamada autenticada à API. O processo deve levar poucos minutos.

​
Pré-requisitos

  • Um endereço de e-mail para verificar a conta.
  • curl e jq para o exemplo com token bearer abaixo.

​
Crie uma conta

1

Cadastre-se

Cadastre-se em console.basaltic.sh.O cadastro, a verificação de e-mail e a configuração de faturamento são feitos pelo console e não fazem parte da API pública.
2

Verifique seu e-mail

O cadastro envia um código de seis dígitos. A conta só pode criar recursos depois da verificação.

​
Gere credenciais de API

Seu login no console identifica você como uma pessoa. O acesso programático usa uma conta de serviço e sua chave de acesso. Crie uma no console em Identity & access → Service accounts, ou pela API:
1

Crie a conta de serviço

Uma conta de serviço pertence à conta selecionada e começa sem permissões. Associe uma política da conta que permita as ações necessárias. Para a solicitação abaixo, permita compute:ListInstances. Contas de serviço não podem participar de grupos. O acesso à organização usa uma concessão separada de política da organização.
2

Crie uma credencial para ela

A resposta contém a credencial e seu segredo:
secret_access_key é retornado uma única vez, na criação. Ele não é armazenado em um formato que a API possa exibir novamente. Se você o perder, exclua a credencial e crie outra.

​
Faça uma solicitação

Obtenha um token e envie-o como credencial bearer. Esse é o fluxo completo.
Uma conta nova não tem instâncias. Portanto, uma resposta 200 com uma lista vazia indica que a chamada foi bem-sucedida. Esse é o fluxo padrão de credenciais do cliente do OAuth 2.0. Qualquer biblioteca HTTP compatível com OAuth pode executá-lo e renovar o token automaticamente. Seu par de chaves de acesso fornece o identificador e o segredo do cliente.
Os tokens duram uma hora por padrão. Solicite outra duração com duration_seconds, entre 900 e 43200. Valores fora desse intervalo são ajustados aos limites, em vez de recusados.
Duas recusas são parecidas, mas exigem soluções diferentes. invalid_client indica que a chave foi rejeitada: verifique-a ou faça sua rotação. invalid_grant indica que a chave está correta e que sua organização está suspensa ou ainda em integração. Nesse caso, trocar uma chave funcional apenas faria você perder tempo.

​
O armazenamento de objetos usa o mesmo par de chaves

O endpoint compatível com S3 verifica o AWS Signature Version 4, usado por todos os clientes S3. Configure um cliente para acessar o endpoint com o mesmo par de chaves de acesso, sem token:
Uma credencial atende aos dois casos: um token bearer para esta API e o próprio par de chaves para S3. Você não precisa escolher um modo de autenticação ao fazer a solicitação.

​
Próximos passos

Autenticação

Troca de tokens bearer, login pessoal e credenciais temporárias de funções.

Regiões e endpoints

Em qual host cada serviço responde.

Referência da API

Todas as operações e seus esquemas.

Suporte

Quando algo não funciona e você precisa falar com alguém.