Authentication

DatabentoAPI.jl resolves your API key from three sources, in order:

Explicit keyword argument to Historical or Live:

Historical("db-AAAAAAAA…")
Live("db-AAAAAAAA…"; dataset = "GLBX.MDP3")

Config file at default_config_path() (~/.databento/config.toml):
```
api_key = "db-AAAAAAAA…"
```

Environment variable DATABENTO_API_KEY:

$env:DATABENTO_API_KEY = "db-AAAAAAAA…"

export DATABENTO_API_KEY=db-AAAAAAAA…

The first non-empty source wins. If none yield a key, both client constructors throw BentoAuthError.

Inspecting / overriding the lookup

load_api_key is exported so you can pre-check what the package would resolve, or feed your own value to it:

using DatabentoAPI

# What would the constructor use?
key = load_api_key()
# Or pass an explicit override (skips file + env var):
key = load_api_key("db-override")

default_config_path returns the platform-appropriate config location (~/.databento/config.toml on Linux/macOS, %USERPROFILE%\.databento\config.toml on Windows). Override the path with the DATABENTO_CONFIG env var if you want to keep the file elsewhere.

When auth fails

On the Historical API, the client surfaces a BentoAuthError immediately on the first request. On the Live API, connect! performs a CRAM-MD5 handshake and raises BentoAuthError if the gateway rejects the challenge response. The error's msg field includes whatever detail the gateway sent back — usually "invalid api_key" or "key not authorized for dataset".