Authoring and automating check-ins from the CLI

A check-in you can only complete by clicking through the chat UI is a check-in an agent can’t drive. Every step of the lifecycle — creating one from scratch, tuning its schedule, answering it, editing a past response, routing results to a channel — has a headless CLI/API path, all covered here.

Creating a check-in

A check-in needs a name, at least one participant, and at least one question — skip either and create fails fast (checkin_requires_participant / questions_required respectively; an interactive TTY prompts instead of erroring).

dailybot checkin create -n "Daily Standup" \
  --user [email protected] --user "Jane Doe" --team "My Team" \
  --questions-file q.json --json

Users resolve by name, email, or UUID (email lookup needs admin/manager rights). Creating a check-in is open to any authenticated member; configuring, archiving, and editing its questions are admin/manager operations.

Scheduling

dailybot checkin config <followup_uuid> \
  --time 09:30 --days 1,2,3,4,5 --timezone America/New_York \
  --frequency weekly --report-time 10:00

Flag	Values	Notes
--time	HH:MM	Delivery time
--days	0-6 comma list	0 = Sunday; 1,2,3,4,5 = Mon–Fri
--timezone	IANA name	e.g. America/New_York
--frequency	weekly only	--frequency-advanced monthly/custom for anything else — --frequency monthly fails fast
--frequency-advanced	disabled / monthly / custom	Use custom with --cron "m h dom mon dow"
--start-on / --end-on	YYYY-MM-DD	Active window bounds
--participant-timezone / --custom-timezone	flag	Per-participant vs. one shared timezone
--report-time	HH:MM	When the aggregated report posts

Reminders

dailybot checkin config <followup_uuid> --reminders 2 --reminder-interval 30 \
  --reminder-condition smart_frequency --reminder-tone persuasive

--reminders (0–5, 0 = off), --reminder-interval (0–60 minutes between them), --reminder-condition (smart_frequency / fixed_frequency), --reminder-tone (standard / persuasive, anything else → invalid_reminder_tone).

Question authoring

Same four types and report-title rule as forms — text, multiple_choice (--options "A,B,C"), boolean, numeric — and --short-question/--ai-short-question is mandatory on add:

dailybot checkin questions add <followup_uuid> \
  --type text --question "What did you complete yesterday?" \
  --short-question "Yesterday" --required

dailybot checkin questions add <followup_uuid> \
  --type boolean --question "Any blockers?" --short-question "Blockers" --blocker

--blocker marks a question so leaving it blank blocks submission — pair it with boolean questions; answering a blocker question "None" is rejected because it isn’t a valid boolean string (use no / false / 0). Conditional jump logic (--jump-if-equals / --jump-to / --logic-file) works identically to forms, including trigger_form and trigger_checkin actions for chaining into another check-in or form based on an answer.

Completing headlessly

dailybot checkin complete <followup_uuid> \
  -a 0="Shipped the auth refactor with full test coverage" \
  -a 1="Starting the payment integration" \
  -a 2=no \
  --yes

Match the answer to the question’s own type — read it first with dailybot checkin show <followup_uuid> --json if you don’t already know it:

question_type	Answer with
text	Free text
boolean	yes/no, true/false, or 1/0
numeric	A number
multiple_choice	One of the question’s own choices labels

A mismatch returns 400 without saying which question was wrong — check types first for a scripted flow. Backfill or future-date with --response-date YYYY-MM-DD (gated by the check-in’s own --allow-past/--allow-future settings — previous_responses_are_not_allowed / future_responses_are_not_allowed otherwise).

Editing and browsing history

# Override specific answers on an already-submitted response
dailybot checkin edit <followup_uuid> -a 0="Updated answer" --yes

# Every participant's responses over a range (admin/manager can filter --user)
dailybot checkin history <followup_uuid> --days 30 --user <user_uuid> --json

# Delete your own response for a day
dailybot checkin reset <followup_uuid> --yes

Check-in history is team-wide by default (unlike forms, which default to your own responses) — a member always sees only their own regardless of --user, which is admin/manager-only. --user takes a UUID only; resolve names/emails first with dailybot user list --json.

Routing results to report channels

dailybot checkin config <followup_uuid> \
  --report-channel "$STANDUP_CHANNEL_UUID" --report-channel "$LEADS_CHANNEL_UUID"

--report-channel is repeatable, max 3 (too_many_report_channels past that). On config it replaces the entire channel set — list every channel you want active, every time you change it. The aggregated report posts at --report-time if set, summarizing that day’s completions.

Smart / AI settings

dailybot checkin config <followup_uuid> --smart --intelligence --max-clarifying 2

--intelligence requires --smart; --max-clarifying > 0 requires --intelligence — both enforced server-side (intelligence_requires_smart_checkin).

Privacy

dailybot checkin config <followup_uuid> --privacy managers_and_members

Values: only_owner, owner_and_members, managers_and_members, managers_and_admins, org_admins, everyone, custom. --anonymous is irreversible — --no-anonymous on an already-anonymous check-in fails with anonymous_irreversible (unlike forms, where anonymity toggles freely both ways).

Round-trip verification

After any authoring call, read the config back to confirm it landed:

dailybot checkin show <followup_uuid> --json

Cross-references

• The forms lifecycle from the CLI for the identical question-authoring model shared between check-ins and forms.
• /developers/cli for the complete checkin command group.

Browse the Solutions hub for the product-facing tour of automating check-ins end to end.