Authentication

The Dailybot CLI supports two credential types. Personal use hands off through an OTP-derived Bearer session; automation and AI agents use a long-lived API key. Both credentials grant identical access to every non-CLI-only endpoint — that is the parity guarantee at /developers/authentication#parity-guarantee.

1. Personal login (`dailybot login`)

Runs OTP-based authentication in a browser tab. On success, the CLI stores a Bearer session at ~/.dailybot/session.json and transparently refreshes it before it expires. This is the right choice for a developer working from their own machine.

dailybot login
# Opens https://app.dailybot.com/cli-auth in your browser.
# You confirm the code the CLI printed.
# Session is stored locally.

2. API key (`$DAILYBOT_API_KEY`)

A long-lived credential minted from your Dailybot dashboard. No interactive login required. This is the right choice for CI, cron jobs, containers, and any AI agent running in a headless environment.

# In your CI secrets manager, set DAILYBOT_API_KEY.
export DAILYBOT_API_KEY=dbot_...

# The CLI picks it up automatically.
dailybot agent update "Build passed."

Which credential wins when both are present?

A live dailybot login session takes precedence over $DAILYBOT_API_KEY. This matches the developer’s mental model: “if I ran dailybot login, I want to be me”. To confirm which credential is active at any point, run dailybot me.

Parity: what works with either credential

Everything except the four CLI-only endpoints. See the full matrix at /developers/authentication#parity-guarantee. If you observe an endpoint that behaves differently across credentials, please file an issue — it’s a bug against the guarantee.

Renewing a session

CLI Bearer sessions refresh automatically on every command. If you’ve been offline long enough that the refresh token expired, the CLI will ask you to re-run dailybot login. API keys never need refreshing but can be rotated any time from your dashboard.