Backlog

Get all the blocks in the Inbox. The list is in Inbox order: the first item is the top of the Inbox.

• This endpoint has no parameters. It has no pagination, and it returns all the blocks. An unknown query parameter returns 422 with the code validation.
• Each item of backlog is an Inbox block.
• The token must have the events:read or the events:write scope.
• The account needs Reassign Pro. The 7-day free trial includes it.

Response fields

Responses

Capture, update, remove, schedule, or park Inbox blocks in one request. Split raw text into Inbox blocks with AI. Each item in ops is one operation (op). The op field of the item gives the action.

• The token must have the events:write scope.
• The account needs Reassign Pro. The 7-day free trial includes it.
• By default, the request is atomic. If one op fails, Reassign writes no change. Set partial to true to apply the valid ops and to skip the ops that fail.
• Target each block or event one time only in a request. A second op on the same block or event fails with validation.
• An update, remove, or schedule op can target only a block that was in the Inbox before the request. To schedule a new block, capture it first. Then send a second request.

Validation

Reassign checks the body before it runs an op.

• A body that is not valid as a whole returns 422 with the code validation and no rows. For example, ops is missing, ops has less than 1 or more than 50 ops, or the body has an unknown key.
• An op that is not valid becomes an error row with the code validation. The request then follows the rules in "Status of a failed request" below.
• An atomic request with an op that is not valid writes nothing. When each failed op is not valid, the status is 422, and the body has the rows.
• op must be capture, capture_text, update, remove, schedule, or park. An unknown op gets the message Unknown op "<op>". Use one of: capture, capture_text, update, remove, schedule, park.
• name has 1 to 200 characters. notes has a maximum of 2,000 characters. The text of capture_text has 1 to 2,000 characters.
• durationMinutes is a whole number from 5 to 1,440. The minimum is the same as the minimum length of a scheduled event, so you can schedule each block.
• priority is a whole number from 0 to 4. null is not valid. To clear the priority, send 0.
• checklist.items has a maximum of 50 steps. Each text has 1 to 200 characters.
• sourceUrl is an http or https address with a maximum of 2,048 characters.
• plannedDate and plannedUntil are real YYYY-MM-DD dates. The start of a schedule op is a local datetime, YYYY-MM-DDTHH:MM.
• Reassign rejects a field that it does not know, also a field of a different op.
• The message of a bad op names the op and the first bad field, for example Invalid "capture" op. `name`: Too small: expected string to have >=1 characters. An op that is not an object gets the message Each op must be an object.

Ops

Source of a new block

capture and capture_text take an optional calendarId. It sets the Source of each new block. On capture_text, it goes to every block.

• When the Source is a writable task list that takes new items, Reassign also creates the block as a task in that list. The plan must have sync access.
• Reassign creates the task after the request returns. The result shape does not change. The block links to the task when the create is done. When the create fails, the block stays in Reassign only. A retry of the create does not make a second task.
• An id that is not a writable task list of the account fails the op with validation: calendarId "<id>" is not a writable task list that can take a new item. Use a task list `id` from `integrations`, or null.

Areas and activity types

• On capture, null and an omitted areaId or activityTypeId have the same effect: no link.
• On update, null removes the link. An omitted key keeps the link.
• On update, null is a manual choice, also when the block has no link. AI classification does not set that field later.
• An ID that the account cannot see fails the op with not_found, for example No area with id "<id>".

Projects

• capture, capture_text, and update take projectId: the id of a live project from GET /api/v1/categories.
• On capture and capture_text, null and an omitted projectId have the same effect: no project.
• On update, null removes the project and keeps the area. An omitted key keeps the project.
• An unknown or an archived project fails the op with not_found: No live project with id "<id>". A block that already links to an archived project can keep that link.

The area of a project

• When an op changes the project and does not send areaId, the block takes the area of the project. This also replaces an area that the user set by hand.
• When the op sends areaId, the block keeps that area.
• A removal of the project, or the same project again, does not change the area.
• A later change to the area of the project does not change the area of the block.

A block that links to a task

When a block links to a task in a task app, a change of projectId can also move the task.

• The read_only messages are these. <App> is the task app, and <team> is the Linear team of the issue.
  • This project has no <App> list for this account.
  • This project has 2 or more <App> lists. Set "New tasks go to" in project settings.
  • This project has no Linear project for the <team> team.
  • This project has 2 or more Linear projects for the <team> team. Unlink one.
  • <App> tasks cannot move to another project.
• A removal of the project (projectId: null) never fails. For a Linear issue, it also takes the issue out of its Linear project. A list task stays in its list.
• A Microsoft To Do task moves as a new task in the new list.

Priority

• capture and capture_text take priority. When you do not send it, the priority is 0.
• On update, an omitted priority keeps the value.
• On capture_text, priority goes to every block.
• For a block that links to a task in Todoist, TickTick, Linear, or Microsoft To Do, Reassign syncs the priority with the task. Google Tasks has no priority field.
• Reassign sends a priority to the task only after a pull of the task records its priority. Until then, a priority edit stays in Reassign. A task that went onto the dial with no stop in the Inbox never gets this record.

Planned days

• plannedUntil must be after plannedDate. For one day, send plannedDate only. On update, a plannedDate on or after the stored plannedUntil also fails with validation.
• plannedUntil needs a plannedDate. On update, Reassign uses the stored plannedDate when you do not send one.
• On update, plannedDate: null moves the block to "Someday" and removes the range. plannedUntil: null makes the range one day.
• For Todoist, TickTick, Google Tasks, Microsoft To Do, and Linear, you can change plannedDate and plannedUntil, and Reassign sends the date to the task app.
• A change to plannedDate or plannedUntil fails with read_only when the task recurs in the task app, or when the task app cannot take a due date. The message is This block is linked to a task app — its planned day mirrors the task's due date there. Change the date in the task app instead. Change the date in the task app.

Checklist

• checklist replaces all the steps of the block. Send each step that you want to keep. An empty items array removes all the steps.
• To keep a step, send its id from a read. For a new step, do not send an id.
• Reassign removes the spaces at the start and at the end of each text. It drops a step with no text after that.

Enrich

• Set enrich to true on a capture of raw text, for example text from a web page. Do not use it for a name that the user wrote.
• AI can then change the name. It can also set durationMinutes and checklist when you do not send them.
• The fields that you send stay the same. Only the name can change.
• AI enriches only the first 10 captures with enrich in one request. Reassign writes the other captures with no change.
• If the AI call fails, Reassign writes the capture with no change and no error.

Capture text

• Send what the user typed, dictated, or selected as text, with no change. AI splits it into 1 to 10 blocks.
• AI gives each block a name. It also gives notes, a length, and a planned day when the text names them.
• The optional notes, durationMinutes, kind, areaId, activityTypeId, projectId, priority, plannedDate, plannedUntil, and sourceUrl go to every block. Send a field only when the user chose it.
• durationMinutes, plannedDate, and plannedUntil replace the AI values. Reassign adds notes after the AI notes.
• The planned day of the AI comes from the time zone of the user.
• The AI length of a block can be up to 24 hours (1,440 minutes).
• With no calendarId, the text can name one of the writable task lists of the user, for example "add to Todoist Work: call the bank". AI sends that block to the list and removes the list words from the name. AI never picks a list from the topic of a block. Reassign checks the list. An unknown list uses the default Source. This needs a plan with sync access.
• Without AI, Reassign finds a list name only at the start ("add to TickTick Home: …"), in a closing bracket ("… (TickTick Home)"), or at the end ("… in TickTick Home") of the text.
• When AI does not answer, Reassign makes one block. The first line of text is the name, and the other lines are the notes.
• AI splits only the first 5 capture_text ops of a request. The other ops make one block each.
• The blocks are in the order of the text, at the top of the Inbox. One undo removes all the blocks.

Schedule

• The length of the event comes from durationMinutes of the block. When the block has no length, the event is 1 hour.
• The event keeps the projectId and the priority of the block.
• The event obeys the span rule of an event write: 5 minutes to 168 hours. A block with a stored length under 5 minutes fails the op with validation.
• A blocking event must not overlap a blocking event. An overlap fails the op with conflict. The error of the row has conflicts and nearestSlots.
• A non-blocking block can overlap other events.
• An earlier park in the same request frees its time for a later schedule.
• recurrence makes the event repeat. It is an RRULE, for example FREQ=WEEKLY;BYDAY=MO,WE,FR. A rule with a repeat of less than one day fails with validation.
• When the day of start is not a day of the rule, the result has firstOccurrence: the first day on which the series occurs.

Park

• The event must be a one-off event that is not reviewed. It must be a Reassign event or an event on a calendar that the user owns.
• The new Inbox block keeps the day of the event as plannedDate. It also keeps the projectId, the priority, and the ticked checklist steps. A later schedule gives the ticked steps back to a one-off event. A read of the block does not show them.
• When the event is not eligible, the op fails with permission. For example, you cannot park a recurring event, an occurrence ID (seriesId@YYYY-MM-DD), or a sleep block.

Results

• An error row has an error object with code, message, and optional detail fields. Refer to Error format. A skipped row has a reason.
• When a schedule op applies or a row has a conflict, the response has timezone, the time zone of the times in the rows.
• When one or more ops apply and the server records an undo receipt, the response has undoToken and expiresAt. Send the token to POST /api/v1/actions/undo before expiresAt (30 minutes) to reverse all the ops of the request.
• A request that applies no op has no undoToken. If the server cannot record the undo, the response also has no undoToken, and the changes stay.
• The undo fails with stale when the area, the activity type, the project, or the priority of a block changed by hand after the request. An AI classification after the request does not stop the undo. Refer to Stale tokens.

Status of a failed request

• Reassign rejects the request when one or more ops fail and no op applies. This is also true for a partial request where all the ops fail.
• In an atomic request, one failed op rejects the request. Only the failed ops are error rows. The valid ops are skipped rows.
• The body of a rejected request is { "error": { code, message }, results }. The status follows error.code, as the Responses table shows.
• When all failed ops have read_only, or all have permission, the status is 403. When the codes differ, the status is 400 with batch_rejected.
• A request where one or more ops apply returns 200. Reassign does not reject it, also when the read of a written op fails after the write. That op gets an error row with the code internal and the message The change was saved, but the read-back failed. Read it again. The response keeps any recorded undoToken.

Request body

Response fields

Responses

Most error responses: When no op of the batch applied, the body also has the results rows, so the caller sees which op failed.