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-09-30 · Added — Notifications, personal briefing and scheduled reports (Plan Beta)

• Notification catalogue and personal switches — GET /v1/plan/notifications/catalog/ lists every kind; GET / PUT /v1/plan/me/notifications/ read and change your own switches per kind and channel (DM and/or email), and where DMs go. You are never notified about your own actions.
• Channel routes — organization administrators create routes (/v1/plan/notification-routes/) that post chosen organization kinds (a task completed, a project update, a lead change…) to a chat channel, for the whole workspace or for some boards or projects. Each route has a delivery log and a send-test with ?dry_run=true.
• Scheduled reports — /v1/plan/reports/ schedules a daily, week-start or week-end report on the weekdays and local time you choose, to a channel and/or by email, with a preview on real data, a run log and a send-test.
• Personal daily briefing — GET / PUT /v1/plan/me/briefing/, plus preview/ and send-test/: what you should work on today, by direct message and/or email.
• Also — GET /v1/plan/channels/ to search the channels routes and reports can post to; board attachments (/v1/plan/boards/{board_id}/attachments/); rename on task, comment, project and goal attachments; who reacted on a comment or a project update, and reactions on project updates.

2026-09-30 · Changed — Dailybot Plan: base path /v1/plan/ (Plan Beta)

• Base path. Every Dailybot Plan endpoint lives under /v1/plan/…, with the tasks:read / tasks:write / tasks:admin scopes and the tasks.* webhook events. There is no other prefix.
• CLI 4.0.0 — every Plan command lives under dailybot plan <tasks|task|board|project|goal> …. New tasks notifications|routes|reports|briefing|channels groups and tasks timeline project and milestone filters. Command index: Dailybot CLI for Plan.

2026-09-25 · Added — Inbox mentions filter (Plan Beta)

• Mentions — GET /v1/plan/inbox/?mentioned=true keeps only the events where someone mentioned you, with an exact count and paging. It combines with type (AND).
• Badges per tab — GET /v1/plan/inbox/unread-count/ takes the same mentioned and type filters, so each tab’s badge counts exactly that tab’s rows. With no parameters the answer is unchanged. Both endpoints refuse undeclared parameters with 400 invalid_filter_value.

2026-09-29 · Changed — a personal API key acts as its person on all of Plan (Plan Beta)

• A personal API key is its person. It sees what the person sees (including private boards they belong to), me is the person, and writes are recorded as the person. It can do everything the person can do on every Plan endpoint, including projects, boards, columns, goals, milestones, members, participants, mute, saved views and attachments. No organization-admin role and no scope grant is needed; explicit tasks:* scopes on the key are a ceiling the person chose (tasks:write covers admin operations, tasks:read is read-only).
• Agent and organization keys are unchanged. They never act as a person: 403 insufficient_scope on the endpoints that need a person, 400 actor_required on owner=me. Guests stay refused with 403 guest_not_allowed, with a key or a session.
• Boards gain effective_visibility (org or members): a board inside a members project reads members. Private objects are 404 not found to anyone without a grant.
• CLI 3.19.0: --agent-name / DAILYBOT_AGENT_NAME, task brief, and a login token bound to the API host that issued it. 3.19.1: clearer invalid_agent_attribution guidance. 3.20.0: a personal API key can do everything its person can do on Plan, and task labels is fixed. 3.21.0: milestone and update commands: project milestone-attach, milestone-attachments, milestone-attachment get|rename|delete, milestone-restore, update-get, update-edit, update-delete, update-attach, update-attachments and update-attachment get|rename|delete. 3.22.0: the CLI covers every live Plan operation: task comment-react|comment-unreact, board label update|delete, board visit, tasks recents, tasks attachments-resolve, and task comment --reply-to <comment-uuid>. It also hardens sign-out (logout revokes every session) and downloaded file names. See Authentication for Plan and Agent attribution.

2026-09-29 · Added — Milestones and project updates (Plan Beta)

• Milestones and project updates — new POST …/milestones/{milestone_id}/restore/; attachments on milestones and on project updates (GET|POST(multipart, up to 5 MiB) …/attachments/, GET|PATCH(rename)|DELETE …/attachments/{attachment_id}/ and GET …/attachments/{attachment_id}/content/); and GET|PATCH|DELETE …/updates/{update_id}/. Reference files with attachment:{uuid} markers. Milestones gain attachment_count; updates carry executed_by_agent, provenance, edited_at and attachments. Only an update’s author edits it or attaches to it (403 update_not_author, a new code); the author or an organization admin deletes it. Send agent_name to co-author an update with an agent.

2026-09-29 · Added — Agent attribution on Plan (Plan Beta)

• Name the agent on a write — every mutating /v1/plan/ endpoint accepts agent_name in a JSON body, or the X-Dailybot-Agent-Name header (percent-encoded UTF-8) on multipart and body-less writes. The body wins; the maximum is 128 characters, and a longer or undecodable name is 400 invalid_agent_attribution. An agent-type key that sends it gets the same error. The stamp never changes a permission answer.
• Responses — comments, attachments and activity items carry executed_by_agent ({uuid, name, username, avatar} or null); a task gains executors (newest first, with first_at and last_at), separate from the singular executor.
• Keys — a personal API key acts as its person (see the entry above). Private objects stay 404 for anyone not invited. See Agent attribution.

2026-09-26 · Changed — Open-org Plan permissions (Plan Beta)

• Every non-guest member holds tasks:read, tasks:write and tasks:admin. Members can create goals, projects and boards (and manage states and memberships). tasks:admin means container writes — it is no longer org-admin only. Guests stay refused with 403 guest_not_allowed before entitlement.
• Invite is the access lever. Privacy is membership, not org role. Org-wide containers are a shared workspace. A members project or board is 404 (not visible) without a grant. Invite a person or a team; the last grant on a private container is 409 last_grant_cannot_be_removed. No per-project roles (lead/viewer).
• Oversight: organization admins and managers of all teams can see every project; a members board still needs a grant.
• Organization API keys still never hold tasks:admin — they cannot change who can see (membership) or who is notified (participants) (403 insufficient_scope).
• PATCH /v1/plan/projects/{project_id}/ persists visibility and auto-grants the actor who privatizes (org → members). See Authentication for Plan.

2026-09-25 · Added — Attachments on comments, goals and projects (Plan Beta)

• Comment attachments — GET/POST /v1/plan/tasks/{task_id}/comments/{comment_id}/attachments/, GET …/{attachment_id}/content/ and DELETE …/{attachment_id}/. Only the comment’s author attaches; the uploader, the comment’s author or an organization admin can remove. Comment rows now carry attachments, their ready attachments by position.
• Project and goal attachments — the same four operations under /v1/plan/projects/{project_id}/attachments/ and /v1/plan/goals/{goal_id}/attachments/. Anyone who can see the project or goal can list and download; uploading and removing need a signed-in non-guest member with tasks:admin (every non-guest member holds it; an API key gets 403 insufficient_scope).
• Upload rules — multipart/form-data only (file, optional caption), up to 5 MiB (400 attachment_too_large with extra.max_size_bytes), the same file types as task attachments, and at most 50 per comment, project or goal. Downloads stream the bytes with nosniff and no-store. Reference an image in a description as attachment:{uuid} and resolve it to the list’s signed url, which expires after 15 minutes.
• Activity — task.comment_attached, task.comment_detached, goal.attached, goal.detached, project.attached and project.detached appear in activity; they are not webhook events.

2026-09-25 · Security + Added + Changed — Dailybot Plan API (Beta)

• Security: keys are refused on every tasks:admin operation — creating, editing, archiving and restoring projects, boards, workflow states and goals, reordering states, managing board and project members, and linking goals to projects need a signed-in non-guest member (tasks:admin; every non-guest member holds it after login). An organization API key gets 403 insufficient_scope. See person-only endpoints. Superseded in part by the 2026-09-26 open-org change above (members, not only org admins).
• Security: the mention picker no longer returns email addresses — rows from GET /v1/plan/boards/{board_id}/mentionables/ are {uuid, name, handle, avatar_url, has_photo, kind} with no email, and q matches a name, handle or external id, never a whole email address.
• Added: bulk create can land at the top — POST /v1/plan/tasks/bulk/ with operation: create accepts an optional position: start puts the new tasks at the top of each column, in item order; end (the default) keeps them at the bottom.
• Added: the mention picker carries avatars — each row now has avatar_url (string or null) and has_photo, with the same meaning as on a task owner: when has_photo is false, show initials. On an agent row they are null and false.
• Changed: dry-run doors document their preview — archiving a project, board, workflow state, task or goal, and completing a milestone, answer a DryRunPreview with ?dry_run=true: {operation, dry_run, reversible, restore_path, consequence, affects}, plus would_refuse and refusal_code on a workflow state archive. Bulk keeps its own preview.
• Changed: bulk dry-run previews report every change — POST /v1/plan/tasks/bulk/?dry_run=true now lists changes to labels, rank, estimate and start_date in changes.

2026-09-25 · Added — Dailybot Plan API (Beta)

• Plan API, in Beta — 117 operations under /v1/plan/ for projects, goals, boards, workflow states, tasks, comments, attachments, favorites, saved views, activity, inbox, timeline and search. Everything under /v1/plan/ is labelled Beta and may change before general availability. Until your organization is enabled, Plan endpoints answer 402 plan_upgrade_required; write to [email protected] to join.
• Home in one request — GET /v1/plan/pulse/ accepts include=projects,attention,activity,goal_progress, and the response states its population as scope: "viewer_visible".
• Batched project updates — GET /v1/plan/projects/updates/ returns the newest updates across every project you can see.
• My tasks — GET /v1/plan/me/tasks/counts/ adds by_scope with {total, open, overdue, blocked}, and the state filter on GET /v1/plan/me/tasks/ accepts state uuids or open / done.
• Bulk previews — POST /v1/plan/tasks/bulk/?dry_run=true runs the call and rolls it back.
• Faster reads — Plan reads are faster, with unchanged responses.
• Delta feed — since on GET /v1/plan/boards/{board_id}/delta/ is a deprecated alias of updated_since; send updated_since. No removal date has been announced.

Documented at /developers/plan and the six Plan groups of the API reference.

2026-08-25 · Added — CLI Labels/Featured, team approver DMs, and programmatic approvals

• CLI & Agent Skill — dailybot label … and dailybot featured … wrap organization Labels and per-user Featured (dailybot-cli >= 3.9.0). Agent sub-skills dailybot-labels and dailybot-featured mirror the same surface.
• Forms approval — team fan-out — When a form lists a team as approver, each active member receives the Approve/Deny chat notification (Slack DM). Individual named approvers still receive DMs as before.
• Forms approval — API / CLI decisions — POST /v1/forms/{uuid}/responses/{uuid}/approval/ with action_status (approved|denied) and optional comment when comments are enabled. CLI: dailybot form response approve|deny.
• Web app — Team approvers can Approve/Deny from the response modal when the API exposes user_can_approve (including team membership).

Documented at /developers/cli, /developers/agent-skill, and /developers/api/forms.

2026-08-03 · Added — Organization Labels, personalization, and forms approval comments

• Organization Labels — Public CRUD under /v1/labels/ (entitlement, archive, associated items) plus POST assign/batch on forms, automations, and check-ins. Entitled when the Labels feature is enabled for the organization and the caller is not a guest; guests denied. List filters: labels= (match-any / OR within the comma-separated set), featured=, prioritize_featured=true. Compact labels: LabelSummary[] and caller-private is_featured on list rows (and on Forms detail).
• Personalization (/v1/me/...) — Dashboard preferences per surface, saved views, and Featured toggles. Not gated by Labels entitlement. Empty dashboard preference → 200 with empty filters; DELETE is idempotent (204).
• Forms approval comments — Public form payloads add read-only approval_flow_comments_enabled. When enabled in form Setup, approvers may leave an optional short comment on web (over-limit rejected); Slack opens a modal. Microsoft Teams, Discord, and Google Chat do not collect approval comments from chat today — use the web app. Configure in the product UI only — not via PATCH /v1/forms/{uuid}/config/.
• Dashboard list enrichment — When enrichment is temporarily unavailable, enrichment query params return 503 with dashboard_enrichment_temporarily_unavailable. See /developers/errors for Labels/personalization codes and retry guidance.

Documented at /developers/api/labels, /developers/api/users, /developers/api/forms, /developers/api/check-ins, and /developers/api/workflows.

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.