Skip to main content
Esta guía te lleva desde el inicio hasta una llamada autenticada a la API. El proceso debería llevar unos minutos.

Requisitos previos

  • Una dirección de correo electrónico para verificar la cuenta.
  • curl y jq para el ejemplo con token bearer de abajo.

Crea una cuenta

1

Regístrate

Regístrate en console.basaltic.sh.El registro, la verificación del correo y la configuración de facturación se realizan en la consola y no forman parte de la API pública.
2

Verifica tu correo electrónico

El registro envía un código de seis dígitos. La cuenta solo puede crear recursos después de verificarse.

Genera credenciales de API

Tu inicio de sesión en la consola te identifica como una persona. El acceso programático usa una cuenta de servicio y su clave de acceso. Crea una en la consola en Identity & access → Service accounts, o mediante la API:
1

Crea la cuenta de servicio

Una cuenta de servicio pertenece a la cuenta seleccionada y empieza sin permisos. Asocia una política de cuenta que permita las acciones necesarias. Para la solicitud de abajo, permite compute:ListInstances. Las cuentas de servicio no pueden pertenecer a grupos. El acceso a la organización usa una concesión de política de organización independiente.
2

Crea una credencial para ella

La respuesta contiene la credencial y su secreto:
secret_access_key se devuelve una sola vez, al crear la credencial. No se almacena en un formato que la API pueda mostrar de nuevo. Si lo pierdes, elimina la credencial y crea otra.

Realiza una solicitud

Obtén un token y envíalo como credencial bearer. Ese es el flujo completo.
Una cuenta nueva no tiene instancias. Por tanto, una respuesta 200 con una lista vacía indica que la llamada se realizó correctamente. Este es el flujo estándar de credenciales de cliente de OAuth 2.0. Cualquier biblioteca HTTP compatible con OAuth puede ejecutarlo y renovar el token automáticamente. Tu par de claves de acceso proporciona el identificador y el secreto del cliente.
Los tokens duran una hora de forma predeterminada. Solicita otra duración con duration_seconds, entre 900 y 43200. Los valores fuera de ese intervalo se ajustan a los límites en lugar de rechazarse.
Dos rechazos se parecen, pero requieren soluciones distintas. invalid_client indica que la clave se rechazó: revísala o rótala. invalid_grant indica que la clave es correcta y que tu organización está suspendida o aún en proceso de incorporación. En ese caso, cambiar una clave que funciona solo te haría perder tiempo.

El almacenamiento de objetos usa el mismo par de claves

El endpoint compatible con S3 verifica AWS Signature Version 4, usado por todos los clientes S3. Configura un cliente para acceder al endpoint con el mismo par de claves de acceso, sin token:
Una credencial cubre ambos casos: un token bearer para esta API y el propio par de claves para S3. No tienes que elegir un modo de autenticación al realizar la solicitud.

Próximos pasos

Autenticación

Intercambio de tokens bearer, inicio de sesión personal y credenciales temporales de roles.

Regiones y endpoints

En qué host responde cada servicio.

Referencia de la API

Todas las operaciones y sus esquemas.

Soporte

Cuando algo no funciona y necesitas hablar con alguien.