Snooze multiple tasks
Snoozes one or more tasks. Supports absolute mode (until) or relative
mode (delta_minutes) — exactly one must be provided.
Priority filtering, by default:
- P0-P2 are always snoozed.
- P3 (High) is snoozed ONLY when no lower-priority task in the same
batch is still eligible. A mixed batch clears P0-P2 and leaves the
High tasks; the next call, finding only High left, takes them. A P4 in
the batch does not hold this back, since a P4 is never swept. - P4 (Urgent) is never snoozed by a sweep — its due date is a hard
deadline and every change to one has to be deliberate. - A task whose DEADLINE HAS PASSED is read as at least P3 (2026-10-12):
it waits while any P0-P2 task without a passed deadline is still
eligible, and goes with the High tier after. A P3 with a passed
deadline is still P3; a P4 is still never swept. Those held back
only by the deadline are counted inskipped_deadline(not in
skipped_urgent).
Callers that represent an explicit user selection (e.g., the mobile
selection sheet's quick panel) should pass include_task_ids so the
listed high/urgent tasks are snoozed anyway.
skipped_urgent keeps its name for client compatibility and counts BOTH
P3 and P4 skips. skipped_high is the P3 subset of it, so a client can
name the two tiers accurately; Urgent alone is the difference.
Each eligible task is changed exactly as PATCH /api/tasks/{id} with
{ due_at } would change it: a dated task's target moves (its
first-target date kept), stopping at a deadline still ahead
(capped_deadline; a passed deadline caps nothing); a
task with no date (absolute mode only) gets its
first date, which is not counted as a snooze; a task already due at
the target is left alone. tasks_affected counts only the tasks whose
date actually moved, so it plus tasks_skipped can be less than the
number of ids.
Authorizations
API token created via POST /api/tokens or the db:create-token CLI command
Request Body
Responses
Bulk operation result