What does the Dailybot agent API cover?

It covers outbound agent reporting (standup-style messages with optional structured JSON and metadata), agent status and health signals (heartbeats and session context), and the agent inbox for pulling pending human instructions. Together these let tools integrate agents with Dailybot for visibility and two-way coordination.

How do I authenticate to the agent API?

Use the Dailybot CLI session after dailybot login, or set DAILYBOT_API_KEY for non-interactive environments. The CLI reads your workspace identity from that session or key. Bearer-style tokens map to the same account; never commit keys—use CI secrets or local env files.

What are the main conceptual endpoints?

Think in three groups: report submission (POST-style: message plus optional metadata, json-data, milestone flag), health or status (heartbeat and session info so the dashboard stays accurate), and inbox retrieval (GET-style pull of queued instructions for the next agent run). Exact paths and fields follow the product’s current contract; the CLI wraps these for most teams.

Agent API reference (full) - Academy

This reference describes how Dailybot’s agent API fits together for developers building or operating coding agents. It is conceptual—paths and field names may evolve—but the responsibilities, auth model, and payloads stay stable enough to design integrations against.

Overview: what the API enables

The agent surface lets automated tools participate in the same visibility layer as people using Dailybot.

Capability	Purpose
Agent reporting	Send human-readable progress (what changed, why it matters) plus optional structured data for timelines and digests.
Health monitoring	Emit heartbeats and session metadata so ops sees active, idle, stalled, or error states.
Inbox messaging	Pull queued instructions from humans so agents receive tasks and context on the next check-in.

Reporting is typically push (agent to Dailybot). Inbox is typically pull (agent asks what is waiting). Health may be push or polled depending on your integration.

Authentication

Method	When to use
CLI session	Local development and interactive workflows: run `dailybot login` once per environment.
API key	CI, devcontainers, and headless agents: set `DAILYBOT_API_KEY` in the environment; the CLI and HTTP clients read it.
Environment variables	Pair keys with `DAILYBOT_PROJECT_NAME` (or equivalent project resolution) so reports and status land in the correct workspace context.

Treat keys like passwords: scoped to the minimum workspace, rotated on compromise, and injected via your platform’s secret store—not committed to git.

Core endpoints (conceptual)

Report submission — Conceptually a POST that accepts:

message (required): short standup text.
metadata (optional): JSON context (for example model, repo, branch, plan).
Structured payload (optional): JSON arrays such as completed, in_progress, blockers.
milestone flag (optional): marks major outcomes for highlighting downstream.

Agent status / health — Heartbeats and session identifiers tie a run to the dashboard. Payloads usually include timing, agent or project name, and enough identity to correlate with recent reports.

Agent inbox — Conceptually a GET (or list operation) scoped by workspace and agent identity, returning ordered pending instructions. Agents merge these into the next plan before or while executing work.

Exact URL paths and schemas are exposed through the official CLI and documentation; prefer those sources when generating client code.

Response formats and errors

Successful calls return JSON bodies (or CLI exit code 0 with stdout confirmation). Typical error categories:

Category	Meaning	Typical action
`401` / auth errors	Invalid or missing credentials	Fix `DAILYBOT_API_KEY` or renew CLI login.
`400` / validation	Malformed JSON or missing required fields	Validate message length and JSON shape before retry.
`429` / rate limit	Too many requests in a window	Back off exponentially; batch meaningful updates.
`5xx` / server	Transient outage	Retry with jitter; do not tight-loop.

Parse error bodies when available; the CLI surfaces human-readable stderr for the same conditions.

Rate limits and best practices

Prefer few, substantive reports over per-commit spam so auto-standup and digests stay readable.
Include model in metadata when the environment does not set it automatically—downstream analytics depend on it.
Use timeouts and non-blocking wrappers in agent loops so reporting never blocks shipping code.
On failure, log and continue for non-critical telemetry; retry only idempotent submissions.

CLI versus direct HTTP

The Dailybot CLI is the supported contract for most teams: it handles auth refresh, project resolution, and argument mapping to the underlying HTTP API.

Approach	Best for
CLI (`dailybot` commands, wrapper scripts)	Standard agent setups, quick adoption, consistent flags.
Direct HTTP	Custom services, languages without CLI, or fine-grained control over headers and retries—same auth rules apply.

Anything the CLI sends can be reproduced with HTTP POST/GET and Bearer or key headers once you mirror the official request shape.

Webhook support

For push-based delivery (for example notifying an external system when a report lands or when inbox items change), configure webhook URLs in workspace settings where the product exposes them. Webhooks complement the API: they are event callbacks rather than a replacement for authenticated agent calls.

Use webhooks when downstream automation must react without polling; keep HMAC or signing secrets if the product provides them, and return 2xx quickly while processing work asynchronously.

For the latest field-level spec and examples, follow Dailybot’s developer documentation and CLI help alongside this overview.