Microsoft To Do
MICROSOFT 365 · TASKS
Task lists kept in Microsoft To Do, scoped to that person.
Connect Microsoft To Do with Fabriq Developer
Your user consents at Microsoft To Do. The credential lands in a vault your agent cannot read, and the tool list it gets back is the intersection of that user’s grant and the agent’s own scopes.
Provider names are surfaces, not vendors, and the authoritative list is the capabilities endpoint rather than any page including this one — an unknown name returns 400 with the valid list. Fabriq Developer is free to start and needs no provider paperwork. Start free or read the quickstart.
Connecting Microsoft To Do in practice
Microsoft To Do has no application permission for creating a task: POST to a task list is marked "Not supported" for app-only in both the /me and /users forms, while listing tasks and updating someone else’s task do have app-only routes. An unattended agent can therefore read and edit a person’s tasks but cannot add one, and its webhooks expire after at most 4,230 minutes, under three days.
Scopes that draw scrutiny
Tasks.ReadWriteDelegated only, no admin consent, available on personal Microsoft accounts, and the only permission that can create a task. It covers the signed-in user’s tasks and task lists "including any shared with the user".Tasks.Read.AllApplication only and admin consent required: "Read all users’ tasks and task lists in your organization, without a signed-in user."Tasks.ReadWrite.AllApplication only and admin consent required. The app-only grant for editing anyone’s tasks, and still not enough to create one.Tasks.ReadWrite.SharedDelegated only and no admin consent, but it extends to tasks shared with the user rather than only their own — more reach than it looks, approved by the user alone.
Rate limits
- Microsoft’s throttling page files the To-do tasks API under the Outlook service, whose per-mailbox limits are 10,000 requests per 10 minutes and four concurrent requests per app ID and mailbox.
- The resources that table actually names are the legacy outlookTask, outlookTaskFolder and outlookTaskGroup types, so no figure is published specifically for the current todoTask surface.
- Change-notification subscriptions on todoTask expire after a maximum of 4,230 minutes (under three days).
- Microsoft Graph global limit: 130,000 requests per 10 seconds per app across all tenants.
Who has to approve
Tasks.Read.All and Tasks.ReadWrite.All exist only as application permissions and both require tenant admin consent, so any unattended access to another person’s tasks needs an administrator. The delegated Tasks.Read and Tasks.ReadWrite do not, and both are available on personal Microsoft accounts.
Worth knowing
- Creating a task is delegated-only, so a daemon cannot file a task on a user’s behalf — it has to hold a user token, which means refresh-token lifecycle rather than client credentials.
- A task’s id changes when the task is moved from one list to another, so ids are not durable keys across lists.
- Change notifications are scoped to one task list (/me/todo/lists/{todoTaskListId}/tasks), so watching a whole account means one subscription per list, each renewed inside three days.
- todoTask webhooks are documented as available only in the global endpoint and not in the national clouds, and the To Do task endpoints are unavailable in the China cloud operated by 21Vianet, so those tenants get neither.
Checked against Create todoTask (permissions table) (2026-09-29), List todoTasks (permissions table) (2026-09-29), Microsoft Graph permissions reference (2026-09-29), Change notifications: supported resources and expiration (2026-09-29)
What an agent can do
Each action is granted on its own. An agent allowed to read is not thereby allowed to write, and the scope beside each row is what the acting user must have connected for it to run at all.
Often connected alongside
Put Microsoft To Do behind one governed endpoint.
Same permissions, same audit trail, whatever else you connect next.