Create an API key and connect securely

API keys let your scripts and applications access your account. Your portal password is not an API key. Hosted AI connections use a separate sign-in and permission flow.

Create a key

1. Open Settings → API and choose Create API key.
2. Give the key a recognizable name, such as “Invoice reports”.
3. Choose signed authentication for an SDK or the CLI, and select the viewing permissions you need.
4. Set an expiry date and create the key.
5. Save the key prefix and the one-time secret in your application's private configuration.

The secret is shown once. If you lose it, create a replacement key. API keys inherit account and project access rules and do not grant access to another customer's services.

Configure the SDK or CLI

Copy the API origin displayed in Settings → API for the portal you are using. The public production origin is https://api.blazingfast.io, used in the example below. Do not append /v1; SDK methods add the route.

Set these environment variables using your terminal or application's private settings:

BF_API_BASE_URL=https://api.blazingfast.io
BF_API_KEY=YOUR_KEY_PREFIX
BF_API_SECRET=YOUR_ONE_TIME_SECRET

Use the actual key values only in your private configuration. Do not paste them into chat or commit them to a repository. Environment files are not loaded automatically by the SDK; your shell or application must load them.

For a bearer-mode key, set BF_API_BEARER to the complete token issued for that key. Use that instead of signed-key credentials.

Choose permissions for a task

The endpoint reference lists permissions for other tasks. Viewing and changing are separate permissions; selecting a write permission does not imply every read permission.

API keys and AI connection policies

API-key calls run directly when the key and your account have the required access. They do not wait for AI dashboard approval.

Hosted AI connections have their own permission checkboxes and policy: Read only, Write with approval, or Full access. Manage those in AI connections. Changing an API key does not change an AI connection.

Keep access current

Use one key per integration so you can identify and revoke it independently. If you add an IP restriction, allow the public outgoing address of the computer running the integration. Review expiry and permissions when a team or application changes. Usage logs in Settings → API show request outcomes.

Building signed HTTP requests yourself

SDKs sign requests for you. A custom client sends x-api-key, x-ts (Unix seconds), x-nonce, x-content-sha256 and x-signature.

Hash the exact request body with SHA-256 and encode the digest in Base64. For an empty body, hash zero bytes. Build the following canonical string with newline separators and no final newline:

UPPERCASE_HTTP_METHOD
/path?exact_query_string
unix_timestamp
unique_nonce
body_sha256_base64

Compute HMAC-SHA256 over that string using the issued secret, then encode the signature in Base64. Keep the original body and query string unchanged after signing, and use a fresh timestamp and nonce for each HTTP attempt. Send Unix seconds within 120 seconds of the server clock. A nonce is 8–200 characters; use a cryptographically random value and never reuse it for the same credential. Reuse is rejected for at least the 300-second replay window. Malformed headers return HTTP 401 with error.code=unauthorized; stale timestamps, replayed nonces, body-hash mismatches and invalid signatures return HTTP 401 with error.code=invalid_signature. Resynchronize your clock and sign a fresh attempt; preserve the original idempotency key for a write. A retry key identifies the action separately from the nonce.