API changelog

Additive changes to the Dailybot public API land continuously. Breaking changes ship behind a new URL prefix (/v2/) with a minimum six-month sunset on the previous version. This page is the running log — add it to your reader and you’ll never have to guess when a new endpoint appeared.

What qualifies as a change

We log four categories: Added (new endpoint, new field on a response, new query parameter), Changed (behavior of an existing endpoint changed in a compatible way), Deprecated (feature we plan to remove, always with the earliest removal date), and Removed (breaking removal, always announced ≥ 6 months earlier under Deprecated). We do not log purely internal changes.

Entries

2026-07-23 · Added — Interactive buttons contract v3.1: Modal → Workflow + {{trigger.*}}

modal_body now composes with callback_workflow (in addition to callback_url). On submit, modal field values are delivered to the triggered api_trigger workflow as {{trigger.fields.<name>}}. Workflow steps gain the canonical {{trigger.*}} namespace (source, body.*, button_id, button_value, fields.*, clicked_at, user.*, triggered_by_user_uuid) for value-branching buttons and modal-to-workflow form pre-fill. Button callback_auth / workflow request_auth credentials are write-only (reads return a *** mask).

Documented at /developers/api/messaging and /developers/api/workflows.

2026-07-23 · Added — api_trigger workflows + POST /v1/workflows/{uuid}/trigger/

New workflow trigger type fired only from outside the engine: the public trigger endpoint (202 Accepted, async run, optional ≤8 KiB JSON payload) or an interactive button’s callback_workflow (resolves exclusively to active api_trigger workflows). Selectable in the automations builder as When triggered via API or button. Errors include workflow_not_triggerable, workflow_trigger_payload_invalid, workflow_execute_not_allowed, and workflow_frozen.

Documented at /developers/api/workflows.

2026-07-23 · Added — request_auth on the Send-a-Request workflow action

The SEND_REQUEST automation step accepts optional static authentication with the same shape as interactive-button callback_auth — bearer, basic, or custom_header (RFC 7230 token; reserved header names denied). Values support {{variables}}; credentials never appear in step outputs.

Documented at /developers/api/workflows (trigger + auth patterns) and /developers/api/messaging (callback_auth).

2026-07-23 · Added — Interactive buttons contract v3: callback_prompt, callback_workflow, response, callback_auth

Four additions to the /v1/send-message/ button envelope: (1) callback_command is a known-command slot (≤200 chars); free-text AI prompts move to callback_prompt (≤2000, runs as the clicker) — the "prompt: …" prefix is rejected with 400 button_callback_command_invalid; (2) callback_workflow (workflow UUID) triggers an internal workflow; (3) response attaches an auto-reply to any button (instant ack in parallel with callback_url, recursive nested buttons with depth/size caps); (4) callback_auth adds optional static transport auth to callback POSTs — additive to the always-on HMAC signature. Mutual exclusivity spans all five callbacks.

Documented at /developers/api/messaging.

2026-07-23 · Added — Interactive buttons: callback_url, modal_body, callback_form, callback_command (778e5d6cd)

An interactive button can trigger signed outbound POSTs to callback_url (HMAC-SHA256, Stripe-style X-Dailybot-Signature: t=…, v1=…, 5-minute replay window, X-Dailybot-Delivery idempotency key), open a platform modal from modal_body, open an internal Dailybot form via callback_form, or run a known command via callback_command. Each interactive button carries a server-minted $btn/<uuid> id. Google Chat is delivered as platform hangouts. Additive — legacy payload.callback_config / action paths continue to work.

Documented at /developers/api/messaging.

2026-07-13 · Added + Changed + Deprecated — Forms list: owner filter, org-wide visibility, and deprecations

• Filter the forms list by owner: pass owner_user_ids=<uuid>,<uuid> to GET /v1/forms/ to see just their forms, and use the new GET /v1/forms/form-owners/ endpoint to discover which members own forms (searchable, paginated). Member emails are hidden in picker payloads unless the caller is an admin or manager.
• No more “missing” forms: every form in your organization now appears in list and search (GET /v1/forms/), so a form can no longer be retrievable by UUID yet absent from the list. Form permissions (edit, see responses, change states) are unaffected.
• Deprecated: filter=me on the forms list — use owner_user_ids with your own UUID instead. available_on_list_view is also deprecated and ignored server-side. Both fields remain accepted indefinitely; removal will be announced as a separate changelog entry with its own migration window.

Documented at /developers/api/forms.

2026-07-12 · Added — Forms API v2: enhanced filtering and automation

Forms list (GET /v1/forms/): Added filter (all/me/public/approval/workflow/archived), order (alphabetical/recent/total), is_ascend, search, include=questions, include_archived, and date range parameters. New response fields: workflow_enabled, approval_flow_enabled, created_at.

Responses list (GET /v1/forms/{uuid}/responses/): Added submission_sources (multi-select: member/anonymous/automation/public), submitter_user_ids (multi-select UUIDs), flow_status (pending/approved/denied), order (recent/oldest), and is_ascend. New response fields: is_anonymous, flow_status, content, submission_source, guest_user. Search now includes submitter name/email.

Submit response (POST /v1/forms/{uuid}/responses/): Added automation mode (no submitter attribution), anonymous mode (random name), guest_user (guest identity for automation), and submission_source (provenance label). New response fields: is_guest_user, guest_user, submission_source.

All new parameters are optional — omitting them produces the same behavior as before. No breaking changes. Documented at /developers/api/forms.

2026-07-10 · Changed — Case-insensitive kudos filter

?filter= on GET /v1/kudos/ and GET /v1/kudos/organization/ now accepts any casing (kudos_received, KUDOS_RECEIVED, Kudos_Received). Invalid values return 400 with code: "invalid_kudos_filter" (replaces not_valid_kudos_filter). Documented at /developers/api/kudos.

2026-07-10 · Added — Form response workflow state filter

GET /v1/forms/{uuid}/responses/?state=<state> filters responses by workflow state on forms with workflow enabled. Invalid states return 400 with code: "invalid_workflow_state". Documented at /developers/api/forms.

2026-07-10 · Added — Search on /v1/kudos/organization/

GET /v1/kudos/organization/ now supports ?search= (case-insensitive substring on kudos content, max 256 chars). Documented at /developers/api/kudos.

2026-07-10 · Changed — Agent endpoints return id and uuid

POST /v1/agent-reports/, GET /v1/agent-messages/, POST /v1/agent-messages/, and pending_messages on GET /v1/agent-health/ now return both id and uuid with the same UUID value for backward compatibility. Prefer uuid in new integrations. Documented at /developers/api/agents.

2026-07-10 · Breaking — Pagination is always-on on all list endpoints

The opt-in mechanism for pagination on GET /v1/forms/ and GET /v1/forms/{uuid}/responses/ has been removed. Every list endpoint now returns the standard { count, next, previous, results } envelope by default. Action required: if you relied on the bare-array response, wrap your consumer in the envelope (response.results). The ?paginated=true query parameter and the X-Dailybot-Paginate header no longer have any effect. Documented at /developers/conventions#pagination.

2026-07-10 · Breaking — Forms endpoints return uuid instead of id

All /v1/forms/** endpoints now return the resource identifier under the uuid key instead of id. This aligns forms with the Dailybot identifier convention — resources with a dedicated UUID column expose uuid; only resources whose primary key IS a UUID expose id. Action required: replace response.id / data["id"] with response.uuid / data["uuid"] in every forms integration. URL paths (/v1/forms/{uuid}/) are unchanged. Documented at /developers/api/forms.

2026-07-10 · Changed — Agent endpoints return uuid

POST /v1/agent-reports/, GET /v1/agent-messages/, POST /v1/agent-messages/, and the pending_messages array on GET /v1/agent-health/ now return the resource identifier under the uuid key. Documented at /developers/api/agents.

2026-07-10 · Added — Filters on /v1/kudos/ and /v1/workflows/

Both endpoints now support ?start_date, ?end_date (YYYY-MM-DD, caller timezone), and ?search (case-insensitive substring on message content for kudos, on workflow name for workflows; max 256 chars). These filters were previously accepted but silently ignored — they are now fully functional. Documented at /developers/api/kudos and /developers/api/workflows.

2026-07-10 · Changed — /v1/kudos/organization/ accepts CLI Bearer tokens

GET /v1/kudos/organization/ used to require an organization API key (X-API-KEY only). It now also accepts CLI Bearer tokens (Authorization: Bearer <token>). The organization admin permission requirement is unchanged. Documented at /developers/api/kudos.

2026-07-10 · Added — New validation error codes

Six new machine-readable error codes are documented and enforced uniformly:

• invalid_user_identifier (HTTP 400) — ?user= is not a valid UUID (applies to /v1/checkins/{uuid}/responses/ and /v1/forms/{uuid}/responses/).
• invalid_date_range (HTTP 400) — date is not YYYY-MM-DD, or start_date > end_date.
• search_query_too_long (HTTP 400) — ?search= exceeds 256 characters.
• invalid_kudos_filter (HTTP 400) — ?filter= on /v1/kudos/ or /v1/kudos/organization/ is not one of kudos_received / kudos_given.
• invalid_workflow_state (HTTP 400) — ?state= on /v1/forms/{uuid}/responses/ is not valid for the form’s workflow.
• form_response_view_all_forbidden (HTTP 403) — member used ?all=true on a restricted form.
• invalid_sender_uuid / invalid_receiver_uuid (HTTP 400) — ?sender_uuid= or ?receiver_uuid= on /v1/kudos/organization/ is not a valid UUID.

All /v1/** error responses are guaranteed to be application/json — no HTML error pages for client-input validation. Documented at /developers/errors#machine-codes.

2026-07-10 · Added — /v1/kudos/organization/ filters, response schema, and error contract

Fully documented the GET /v1/kudos/organization/ endpoint: admin-only, always paginated, ordered by created_at DESC (with id tiebreaker), top-level kudos only. Filters: filter (kudos_received / kudos_given), timezone-aware start_date / end_date, legacy naive-day date_start / date_end (both pairs can stack), plus sender_uuid / receiver_uuid. Response fields (user, receivers, company_value, content, is_anonymous, created_at) and the four 400 validation codes (invalid_date_range, invalid_kudos_filter, invalid_sender_uuid, invalid_receiver_uuid) are now on the endpoint page. Documented at /developers/api/kudos#get-v1kudosorganization.

2026-07-09 · Added — Unified pagination on all list endpoints

All /v1/ list endpoints now return the standard { count, next, previous, results } envelope uniformly. Added canonical page / page_size parameters. Legacy limit / offset remain accepted as aliases. Documented at /developers/conventions#pagination.

2026-07-09 · Added — Search parameter on list endpoints

Added ?search=<term> (case-insensitive substring, max 256 chars) on forms, check-ins, form responses, check-in responses, and users. Returns 400 with code: "search_query_too_long" if over the limit. Documented at /developers/conventions#search.

2026-07-09 · Added — Canonical date range parameters

Unified date-range parameters ?start_date / ?end_date (YYYY-MM-DD, caller timezone) on all paginated endpoints. Legacy aliases date_start/date_end and date_from/date_to continue to work. Returns 400 with code: "invalid_date_range" on malformed dates. Documented at /developers/conventions#date-range.

2026-07-09 · Added — Machine-readable error codes on all error responses

Every non-2xx response now carries a stable code field alongside detail. Dispatch on code, never parse the prose. Full reference at /developers/errors#machine-codes.

2026-07-09 · Added — Free-plan daily throttles on agent-reports and send-email

POST /v1/agent-reports/ is now limited to 50 per org per day on free plans. POST /v1/send-email/ is limited to 20 per org per day on free plans. Excess returns 429 with code: "free_plan_daily_limit_exceeded" and a Retry-After header. Paid plans unaffected. Documented at /developers/rate-limits#free-plan-throttles.

2026-07-09 · Added — send_as_user identity override on POST /v1/send-message/

New send_as_user field (UUID) on POST /v1/send-message/ lets authorized admin callers post a message that appears to come from another user’s Slack identity (display name + avatar). Slack-only. Mutually exclusive with bot_username, bot_icon_url, and bot_icon_emoji. Documented at /developers/api/messaging#send-as-user.

2026-07-09 · Added — API key show-once lifecycle and member access

API key secrets now follow show-once semantics: the full plaintext key is returned only at creation or regeneration; subsequent reads expose only the 4-char key_suffix. Non-admin organization members can now create and manage their own API keys (excluding agent keys). New created_by field on key responses. Documented at /developers/authentication#api-key-secret-lifecycle-show-once.

2026-07-09 · Added — CLI Bearer token free-plan allowlist

CLI Bearer tokens now explicitly document a free-plan endpoint allowlist. POST /v1/agent-reports/ (50/day), POST /v1/send-email/ (20/day), agent-health, agent-messages, and a handful of read endpoints are available on free plans. All other endpoints return 403 with code: "plan_upgrade_required" and an upgrade_url field. Documented at /developers/authentication#cli-bearer-tokens-free-plan-allowlist.

2026-07-09 · Changed — API key works on ALL /v1/ endpoints

Confirmed and documented: API keys are not restricted to agent operations — they work on all /v1/ public endpoints. The prior impression was caused by a CLI client-side limitation, not a server-side restriction. New auth method matrix at /developers/authentication#parity-matrix.

2026-07-09 · Removed — Bare-array pagination opt-in on forms endpoints

The deprecated bare-array default on GET /v1/forms/ and GET /v1/forms/{uuid}/responses/ has been removed. Pagination is now always-on — see the 2026-07-10 breaking change entry above.

2026-07-09 · Deprecated — /v1/followups/ endpoints

GET /v1/followups/ and GET /v1/followups/{uuid}/responses/ are deprecated. Use GET /v1/checkins/ and GET /v1/checkins/{uuid}/responses/ instead. The legacy paths continue to work but will be removed in a future release.

2026-07-07 · Changed — Check-in Responses: default listing restored + user filter

• The GET /v1/checkins/{uuid}/responses/ endpoint now correctly returns all participants’ responses by default (regression from a prior release has been fixed).
• Added optional ?user=<uuid> parameter for admin/manager API key owners to filter responses to a specific participant.
• The ?all=true parameter is not applicable to check-in responses and should not be documented for this endpoint.

2026-07-06 · Added — Forms & check-ins authoring API

Full programmatic authoring for forms and check-ins: create, configure, archive, and question management (add, edit, delete, reorder with conditional logic). New utility endpoint GET /v1/report-channels/. Requires admin/manager role and CLI:write for write operations. Documented at /developers/api/forms and /developers/api/check-ins.

2026-07-06 · Changed — Stricter config validation and form response listing filters

Form and check-in config endpoints reject unknown fields with 400 unknown_field. List endpoints support include_archived. Form response listing (not check-in responses) supports all, user, date_from, date_to (admin-scoped). Admins can edit others’ form responses (audit via metadata.last_edited_by).

2026-07-02 · Added — Trilingual API reference at /developers/api/

Every one of the 101 public API endpoints across 18 groups now has a dedicated reference page rendered from a content collection. Each endpoint documents auth methods, parameters, request/response schemas, error codes, and rate-limit scope. Trilingual mirrors under /es/ and /pt/.

2026-07-02 · Commitment — Parity commitment: API key vs. CLI Bearer

Formalized the design commitment that every non-CLI-only endpoint accepts both credential types with identical response shape. See /developers/authentication#parity-guarantee. Rollout of the api-services enforcement is tracked and will be logged here when complete.