Authentication

Authenticate to Nebula Block with an API key or a login access token, and manage key rotation.

Every Nebula Block endpoint requires authentication, so the platform knows whose resources to read or change. There are two credential types:

• API keys — long-lived, for applications and servers

• Access tokens — short-lived JWTs, for interactive sessions

Both use Bearer authentication:

Authorization: Bearer <key or token>

API keys

API keys are the right choice for anything running unattended: they do not expire, and you can disable or delete one without touching the rest of your account.

Authorization: Bearer sk-...

API keys are prefixed with sk-, which is how they are told apart from access tokens. The same key authenticates both the Inference API and the Platform API.

Create and manage keys in the console under API Keys, or through the API — see Create API Key. A few constraints worth knowing:

• Key names must be unique within your account.

• An account can hold up to 20 API keys. Contact support if you need the cap raised.

• Keys cannot be regenerated in place. To rotate one, create a replacement and delete the old key.

• A key can be disabled and re-enabled with Update API Key, which is safer than deleting if you only need to cut access temporarily.

Important: Key values are readable after creation — both List API Keys and the console return them in full. Treat a key like a password: keep it out of source control, and rotate it if you suspect it has leaked.

Access tokens

Access tokens are JWTs issued by the login endpoint. They suit interactive tools and the console, where a human has just entered credentials.

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Note: Access tokens expire 24 hours after they are issued. Once one expires, requests fail with 401 and you need to log in again for a new token. For anything long-running, use an API key instead.

Login

HTTP Request

POST {API_URL}/login

where API_URL = https://api.nebulablock.com/api/v1.

The endpoint takes OAuth2 password-form input, so the body must be form-encoded, not JSON.

Body Parameters

Parameter	Requirement	Type	Description
username	Required	string	Your account email
password	Required	string	Your account password

Response Attributes

data dict

Your account summary plus the access token in jwtToken.

status string

success or failed.

message string

A description of the result.

Example

Request

curl -X POST '{API_URL}/login' \
-H 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'username=[e-mail]' \
--data-urlencode 'password=your-password'

Response

{
    "data": {
        "id": 18,
        "name": "Test User",
        "email": "[e-mail]",
        "is_staff": false,
        "is_active": true,
        "jwtToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
    },
    "message": "Login successful",
    "status": "success"
}

Logout

POST {API_URL}/logout

Invalidates the access token supplied in the Authorization header. API keys are unaffected — delete or disable them instead.

See also

• API Keys

• Platform API

• Inference API