Authentication

Authorization Bearer header

The canonical way to authenticate is to pass your API key as an Authorization Bearer token. This is the standard the Logic64 API validates first on every request.

$ curl https://api.logic64.com/bundles/latest \
    -H "Authorization: Bearer l64_abc12345_e3b0c44298fc1c149afb4c8996fb92427ae41e4649b934ca495991b7852b855"

Replace the example key with your own. The Authorization header must use the Bearer scheme exactly — omitting it or using a different scheme will result in a 401 response.

Legacy X-API-Key headerdeprecated

For backward compatibility, the API also accepts the key in an X-API-Key header. Existing integrations using this header will continue to work, but all new code should use Authorization: Bearer instead.

# Legacy — accepted but not recommended
$ curl https://api.logic64.com/bundles/latest \
    -H "X-API-Key: l64_abc12345_e3b0c44298fc1c149afb4c8996fb924..."

When both headers are present, Authorization: Bearer takes precedence. Migrate to the Bearer scheme at your next opportunity; the X-API-Key header may be removed in a future major version.

Storing keys with the CLI

The logic64 auth command stores your API key securely in a local config file in your home directory, so you do not have to pass it manually on every command.

$ logic64 auth --api-key l64_abc12345_e3b0c44298fc... --api-url https://api.logic64.com
# ✓ Authenticated. Key stored in ~/.logic64/config.json

• --api-key — your full API key, including the l64_ prefix.
• --api-url — the base URL of the Logic64 API. Use https://api.logic64.com for production.
• The key is saved to ~/.logic64/config.json in your home directory. On Windows this resolves to %USERPROFILE%\.logic64\config.json.
• Subsequent commands (logic64 pull, logic64 export, etc.) read the key from this file automatically.

Using environment variables

For CI/CD pipelines, Docker environments, and any automated context where you cannot run logic64 auth interactively, set the LOGIC64_TOKEN environment variable. The CLI and any direct HTTP client can read the key from this variable.

# In your CI environment or shell profile
export LOGIC64_TOKEN="l64_abc12345_e3b0c44298fc1c149afb4c8996fb924..."
# The CLI reads LOGIC64_TOKEN automatically — no --api-key flag needed
$ logic64 pull <bundle-id>

• Never hard-code keys in source files. Use your CI platform's secrets store (GitHub Actions Secrets, environment-level variables, etc.) to inject LOGIC64_TOKEN at runtime.
• Never commit .env files containing the key. Add .env to .gitignore and use a .env.example with placeholder values instead.
• If both LOGIC64_TOKEN and a local config file are present, the environment variable takes precedence.

Rotating keys

Regular key rotation reduces the blast radius of a compromised credential. The recommended rotation procedure is a zero-downtime swap performed entirely from the Studio dashboard:

• Open Studio → Settings → API Keys and create a new key. Give it a descriptive name so you can distinguish it from the old one (e.g., prod-2026-05).
• Update all consumers — your CLI config, CI secrets, and any direct integrations — to use the new key. Verify each one is working correctly before proceeding.
• Return to the API Keys page and revoke the old key. It will stop working immediately.

Rotate keys proactively on a schedule (for example, every 90 days) and reactively any time a key may have been exposed — even accidentally logged in a terminal or CI output.

Revoking keys

Revoking a key from Studio → Settings → API Keys invalidates it immediately. Any in-flight or future request that carries the revoked key will receive a 401 INVALID_API_KEY response — there is no grace period.

• Revocation takes effect instantly across all Logic64 services.
• Revoked keys cannot be un-revoked. If you revoke a key by mistake, create a new one and update your integrations.
• If you believe a key has been compromised, revoke it immediately — before rotating — to cut off unauthorized access as fast as possible.

401 INVALID_API_KEY

When a request is rejected due to a missing, malformed, or revoked API key, the API returns HTTP 401 with a JSON body that includes a machine-readable code and a human-readable hint:

{
  "code": "INVALID_API_KEY",
  "hint": "Run: logic64 login"
}

Common causes and remediation steps:

• Missing header: The request did not include an Authorization or X-API-Key header. Add Authorization: Bearer l64_....
• Revoked key: The key was revoked from Studio. Create a new key and update your configuration.
• Malformed key: The key does not match the l64_prefix8_hex32 format — check for accidental truncation or extra whitespace.
• CLI not authenticated: Run logic64 auth --api-key l64_... --api-url https://api.logic64.com to store a valid key locally.

Best practices

Following these guidelines keeps your API keys and the projects they protect as safe as possible:

• Separate keys per environment. Use one key for local development, a different key for staging, and a dedicated key for production. Compromising a development key cannot affect production workspaces.
• Least-privilege scoping. When possible, create one key per project. A key scoped to a single project limits the damage if it is ever exposed.
• Never log keys. Ensure your application, CI pipeline, and any observability tooling strip or mask the secret suffix of any API key before writing to logs. The public prefix (l64_prefix8) is safe to log; the hex suffix is not.
• Treat keys as passwords. Store them in a secrets manager, not in code, config files checked into version control, or chat tools. If a key leaks, revoke it immediately.
• Rotate on a schedule. Establish a rotation cadence (for example, every 90 days) and rotate immediately whenever a key may have been exposed.
• Use LOGIC64_TOKEN in CI/CD. Inject the key as a CI secret at runtime — never bake it into Docker images or repository files.