Skip to main content
This walks you from nothing to an authenticated API call. It should take a few minutes.

​
Prerequisites

  • A way to receive email, to verify the account.
  • curl and jq, for the bearer-token example below.

​
Create an account

1

Sign up

Register at console.basaltic.sh.Signing up, verifying your email and setting up billing are console flows — they are not part of the public API.
2

Verify your email

Registration sends a six-digit code. The account cannot create resources until it is verified.

​
Issue API credentials

Your console login signs you in as a person. Programmatic access uses a service account and its access key instead. Create one in the console under Identity & access → Service accounts, or over the API:
1

Create the service account

A service account belongs to the selected account and starts with no permissions. Attach an account policy allowing the required actions. For the request below, allow compute:ListInstances. Service accounts cannot join groups. Organization access uses a separate organization policy grant.
2

Create a credential on it

The response carries the credential and its secret:
secret_access_key is returned once, at creation. It is not stored in a form the API can show you again. If you lose it, delete the credential and create another.

​
Make a request

Get a token, then send it as a bearer credential. That is the whole flow.
A fresh account has no instances, so a healthy response is 200 with an empty list — that is the call succeeding, not failing. This is standard OAuth 2.0 client credentials, so any OAuth-aware HTTP library will do it for you and refresh on its own. Your access key pair is the client id and client secret.
Tokens last an hour by default. Ask for a different lifetime with duration_seconds, between 900 and 43200 — values outside that range are clamped rather than refused.
Two refusals look similar and have opposite fixes. invalid_client means the key was rejected — check or rotate it. invalid_grant means the key is fine and your organization is suspended or still onboarding, where rotating a working key would only cost you time.

​
Object storage uses the same key pair

The S3-compatible endpoint verifies AWS Signature Version 4, because that is what every S3 client speaks. Point one at the endpoint with the same access key pair — no token involved:
So one credential covers both: a bearer token for this API, the key pair itself for S3. There is nothing to choose between at request time.

​
Where to go next

Authentication

Bearer token exchange, personal sign-in, and temporary role credentials.

Regions and endpoints

Which host each service answers on.

API reference

Every operation, with schemas.

Support

When something is wrong and you need a person.