Todoist automations

Importing or creating more than roughly 50 tasks in rapid succession will exhaust Todoist's 1,000-requests-per-15-minute rate limit faster than most automation builders expect, especially if each task creation includes label, due date, or project assignment as separate API calls. The result is a wave of HTTP 429 errors — Zapier, Make, and Pipedream will each handle retries differently, and without explicit queue logic, tasks created mid-batch are dropped without any error surfaced to the user. A chunked approach processing ~50 tasks at a time with delays between batches is the minimum viable mitigation.

At moderate event volumes, Todoist webhook delivery becomes unreliable enough to cause real data gaps — payloads can arrive out of order, duplicated, or not at all, with no built-in retry guarantee and no failure notification sent to your endpoint. Workflows in n8n that rely solely on webhooks to trigger task updates have been confirmed silently non-functional in community reports from January 2026. Any automation handling time-sensitive events like deadline changes or task completions at scale needs a scheduled polling job as a reconciliation layer alongside webhook listeners.

The migration from REST API v2 to the unified v1 invalidated every task, project, section, and label ID previously issued by Todoist — these IDs changed and the old values return errors, often silently depending on how the automation platform handles API failures. Workflows in Make, Zapier, n8n, or Pipedream that store a Todoist project ID in a data store, Google Sheet, or static configuration field to route incoming items will misfire or fail entirely without surfacing a clear error. This is a full audit requirement, not a minor update.