Agent reports API: the complete guide

The agent reports surface is how Dailybot turns invisible coding work into updates your team can actually read. Whether you call it through the Dailybot CLI or a thin wrapper script, the same contract applies: authenticate, send a clear message, attach structured data only when it helps, and let metadata carry context for the timeline.

How requests are structured

The supported path for most teams is the CLI command dailybot agent update. Conceptually, it maps to an authenticated request to Dailybot’s agent reporting backend: your identity proves which organization receives the update, --name scopes the report to a project or agent label, and the body combines the message with optional flags the service turns into timeline entries.

You do not need to hand-craft raw HTTP for standard setups. Treat the CLI as the stable contract: message first, then optional --milestone, --json-data, --metadata, and --co-authors when a human asked you to credit someone.

Authentication

Authentication flows through the Dailybot CLI session or an API key. Run dailybot login (or use dailybot login with email and code flags in automated environments), or configure DAILYBOT_API_KEY so agents never prompt interactively. The agent_scripts/dailybot-report.sh wrapper checks dailybot status and exits quietly if the CLI is missing or not logged in, which avoids breaking agent workflows while still surfacing a clear warning in logs.

For ops teams, standardize DAILYBOT_PROJECT_NAME (or .dailybot.env / .env / devcontainer name) so every report lands under the correct project without per-run arguments.

Payload: message, metadata, and json-data

Message — Required. One to three sentences in standup style: what shipped or changed and why it matters. This is what managers scan first.

metadata — JSON object with contextual keys. The reporter script merges auto-detected fields (repo, agent_tool, model, branch) with anything you pass via --metadata. Pass at least model when your environment does not set DAILYBOT_AGENT_MODEL.

json-data — Optional JSON for structured progress. Common shape:

{"completed":["Item one","Item two"],"in_progress":["Item three"],"blockers":[]}

Use it for plan wrap-ups or multi-deliverable work; skip it for single small fixes.

milestone — Optional flag marking a significant outcome (launch, refactor complete, migration done).

Together, these fields are what the product uses to render rich entries in the feed and downstream summaries.

Responses, errors, and retries

Successful submissions are acknowledged by the CLI; failures typically reflect auth, validation, or transient network issues. The official reporter script wraps the call in a short timeout and always exits zero so agents never block on reporting. For direct dailybot agent update usage, treat non-zero exit or timeout as a signal to log and retry with exponential backoff—do not tight-loop retries. Parse human-readable CLI stderr when debugging.

Rate limits and best practices

Dailybot expects meaningful reports, not per-commit noise. Align with the same guidance as human standups: roughly a handful of substantive updates per agent per day, combining related work into one message. Heavy automation should backoff when responses indicate throttling or repeated failures. Prefer quality over volume so auto-standup and digests stay readable.

CLI wrapper versus direct calls

agent_scripts/dailybot-report.sh adds project name resolution, metadata auto-detection, non-blocking behavior, and a bounded timeout around dailybot agent update. Use it inside Claude Code, Cursor, Codex, or CI hooks when the script is available.

Use direct dailybot agent update when you control all arguments yourself (custom --name, minimal metadata, or integration tests). Both hit the same underlying reporting path.

Product integration

This reporting path powers auto-standup: agent output can fill or supplement a developer’s standup when configured. Reports also flow into the unified timeline, so human check-ins and agent updates tell one story. Getting payload shape and authentication right means your org sees accurate, comparable history in one place.