> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coderabbit.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Run coding tasks with the API

> Create a Coding Agent task, follow its turns, answer its questions, review and approve its plan, work with plan feedback threads, and deliver the patch.

Use this recipe to drive [Coding Agent](https://docs.coderabbit.ai/code.md) from a script or an agent: create a task, follow it, review its plan, and deliver its patch. The task page in the app shows the same task, so people can follow and steer it there too.

## Before you start

* You need a user or agentic API key for a [GitHub Cloud organization](https://docs.coderabbit.ai/api.md#availability) that can use Coding Agent; if the same job also [requests CodeRabbit reviews](https://docs.coderabbit.ai/api/guides/pull-request-reviews.md#3-request-a-review), use an agentic key for the whole flow. See [Authentication](https://docs.coderabbit.ai/api/authentication.md#which-keys-each-operation-accepts) for keys and [Conventions](https://docs.coderabbit.ai/api/conventions.md) for base URLs, pagination, errors, and rate limits.
* Tasks act as the key's owner: that person's repository access, Coding Agent permissions, and billing apply. See [Access and billing](https://docs.coderabbit.ai/code/access-and-billing.md).
* The curl examples read the key from `CODERABBIT_API_KEY` and the API host from `CODERABBIT_API_HOST`; [Set up your shell](https://docs.coderabbit.ai/api/quickstart.md#set-up-your-shell) sets both. The CLI has no dedicated commands for these operations; the CLI examples call them through [`coderabbit api request`](https://docs.coderabbit.ai/api/cli). To work with tasks interactively in a terminal, use [`cr code`](https://docs.coderabbit.ai/cli/cloud-tasks) instead.
* On the [hosted MCP server](https://docs.coderabbit.ai/api/mcp.md), every operation on this page is a tool with the same name as its operation ID, such as `create_code_task`. Reads need the `code:read` scope and changes need `code:write`.

## 1. Create a task

[Create a task](https://docs.coderabbit.ai/api/reference/create-code-task.md) with a JSON body. Save it as `task.json`:

```json task.json theme={null}
{
  "repository_id": "123456789",
  "branch": "main",
  "instructions": "Add a regression test for the pagination bug in src/list.ts.",
  "mode": "plan",
  "client_request_id": "pagination-test-2026-11-10"
}
```

Set `mode` to `plan` to get a plan to review first; without it, the agent changes code directly. See [Code mode and Plan mode](https://docs.coderabbit.ai/code.md#code-mode-and-plan-mode). `client_request_id` is required: give each new task its own, and a retry with the same ID returns the task already created, as [Retry safely](#retry-safely) explains. [Create a task](https://docs.coderabbit.ai/api/reference/create-code-task.md) lists every field and its limits.

```bash curl theme={null}
curl "$CODERABBIT_API_HOST/v1/code/tasks" \
  --header "x-coderabbitai-api-key: $CODERABBIT_API_KEY" \
  --header "Content-Type: application/json" \
  --data @task.json
```

```bash CLI theme={null}
coderabbit api request /code/tasks --input task.json
```

The response holds the `task` and `created`, which is `false` when the `client_request_id` matched a task you already created. Save `task.task_id`; the examples below read it from `TASK_ID`. Creating a task never pushes code: the work ends as a proposed patch that you deliver in [step 6](#6-deliver-the-patch).

## 2. Follow the task

Poll [Get a task](https://docs.coderabbit.ai/api/reference/get-code-task.md) to see where the task is.

```bash curl theme={null}
curl "$CODERABBIT_API_HOST/v1/code/tasks/$TASK_ID" \
  --header "x-coderabbitai-api-key: $CODERABBIT_API_KEY"
```

```bash CLI theme={null}
coderabbit api request "/code/tasks/$TASK_ID"
```

`status` tells you what the task needs next. These values need your attention:

| `status` | What to do |
| - | - |
| `plan_ready` | A plan is ready. Read it in [step 3](#3-read-the-plan). |
| `patch_ready` | A proposed patch is ready. Review and deliver it in [step 6](#6-deliver-the-patch). |
| `conflicts_detected` | Delivery hit a conflict. See [Resolve delivery conflicts](https://docs.coderabbit.ai/code/deliver-changes.md#resolve-delivery-conflicts). |
| `completed`, `no_file_changes` | The work finished. `pull_request_url` links to the pull request when the task delivered one. |
| `failed`, `canceled`, `rejected` | The latest turn failed, was stopped, or had its patch rejected. Read the turn to see why. |
| `stale` | The task is out of date with the branch it was created against. |

While work is in progress, `status` is `queued`, `running`, `revising`, `applying`, or `resolving_conflicts`. A polling loop stops at `plan_ready`, `patch_ready`, and `conflicts_detected`, which wait for you, and at the final states `completed`, `no_file_changes`, `failed`, `canceled`, `rejected`, and `stale`. A question from the agent doesn't change the task's `status`: while it is `running`, also read the latest turn, and when its `waiting_for_interaction_id` is set, [answer the question](#answer-a-question) before you poll again. Poll every 10 seconds or less often; [Get a task](https://docs.coderabbit.ai/api/reference/get-code-task.md) has its own budget under [rate limits](https://docs.coderabbit.ai/api/conventions.md#rate-limits). `plan_version` is `null` until the task has a plan. [Follow the work](https://docs.coderabbit.ai/code/work-with-a-task.md#follow-the-work) explains the states as the app shows them.

Each instruction the agent works on is a turn. [List turns](https://docs.coderabbit.ai/api/reference/list-code-task-turns.md) returns the newest 20 turns, oldest first. For older turns, pass `next_before_turn_start_seq` as `before_turn_start_seq`. To read what the agent said at the end of a turn, call [Get a turn](https://docs.coderabbit.ai/api/reference/get-code-task-turn.md) with its `start_seq`:

```bash curl theme={null}
curl "$CODERABBIT_API_HOST/v1/code/tasks/$TASK_ID/turns/$TURN_START_SEQ" \
  --header "x-coderabbitai-api-key: $CODERABBIT_API_KEY"
```

```bash CLI theme={null}
coderabbit api request "/code/tasks/$TASK_ID/turns/$TURN_START_SEQ"
```

A turn's `status` is `running`, `patch_ready`, `completed`, `canceled`, or `failed`. For a `completed` or `patch_ready` turn, `result.text` holds the agent's final reply. `result` is `null` while the turn runs or when no final reply was kept. A `failed` turn has a general `error.message`; open the task in the app for details. Old turns eventually return `404 not_found`.

### Answer a question

When the agent needs your input, the turn's `waiting_for_interaction_id` is set. [List questions](https://docs.coderabbit.ai/api/reference/list-code-task-questions.md) and find the entry whose `question.interactionId` matches it. Each item in `question.questions` has an `id`, the `question` text, and sometimes `options` to choose from.

Answer with [Answer a question](https://docs.coderabbit.ai/api/reference/answer-code-task-question.md). `client_operation_id` must be a UUID, and `answers` maps each question `id` to your answers:

```json answer.json theme={null}
{
  "client_operation_id": "6f1c2d4e-8a9b-4c3d-9e2f-1a2b3c4d5e6f",
  "answers": {
    "QUESTION_ID": { "answers": ["Keep the current retry behavior"] }
  }
}
```

```bash curl theme={null}
curl "$CODERABBIT_API_HOST/v1/code/tasks/$TASK_ID/questions/$INTERACTION_ID/answers" \
  --header "x-coderabbitai-api-key: $CODERABBIT_API_KEY" \
  --header "Content-Type: application/json" \
  --data @answer.json
```

```bash CLI theme={null}
coderabbit api request "/code/tasks/$TASK_ID/questions/$INTERACTION_ID/answers" --input answer.json
```

The response's `result` is `accepted`, `duplicate`, `deferred`, or `rejected`, with a `reason` when it has one. Prompts that ask for permission to use the owner's personal connections, or ask how to deliver the work, return `412 precondition_failed`; answer those on the task page in the app.

### Send a follow-up or stop a turn

* To give the agent another instruction, [send a follow-up](https://docs.coderabbit.ai/api/reference/create-code-task-turn.md) with `message` and a `client_operation_id`. CodeRabbit queues it and runs it as a new turn; [Get the queue](https://docs.coderabbit.ai/api/reference/get-code-task-queue.md) shows messages still waiting.
* To stop the running turn, [stop the task](https://docs.coderabbit.ai/api/reference/cancel-code-task-turn.md), optionally with a `reason`. It works like **Stop** on the task page, including what happens to queued messages; see [Stop a task](https://docs.coderabbit.ai/code/work-with-a-task.md#stop-a-task). It doesn't stop CodeRabbit reviews.

Both calls return `202` when CodeRabbit accepts them. Keep polling the task for the result.

## 3. Read the plan

In plan mode, the task stops at `plan_ready` with a `plan_version`. [Get the plan](https://docs.coderabbit.ai/api/reference/get-code-task-plan.md) for that version:

```bash curl theme={null}
curl --get "$CODERABBIT_API_HOST/v1/code/tasks/$TASK_ID/plan" \
  --header "x-coderabbitai-api-key: $CODERABBIT_API_KEY" \
  --data-urlencode "version=$PLAN_VERSION" \
  --output plan.json
```

```bash CLI theme={null}
coderabbit api request "/code/tasks/$TASK_ID/plan?version=$PLAN_VERSION" > plan.json
```

`PLAN_VERSION` is the task's `plan_version`. The response has the plan's `markdown`, its `approvals`, and the `version` and `sha256` that identify this exact plan. Every revision creates a new version. Feedback and approval calls take both `version` and `sha256`, and return `409 conflict` when they don't match the current plan; read the task and the plan again, then decide how to continue. The examples below read the hash from `PLAN_SHA256`:

```bash theme={null}
PLAN_SHA256=$(jq -r '.sha256' plan.json)
```

## 4. Work with plan feedback

People start feedback threads by selecting plan text on the task page; the API can't start a thread, but it can reply to, resolve, and reopen the threads that exist. A script that wants to send feedback shouldn't wait for a thread: [revise the plan](#5-approve-revise-or-implement-the-plan) with a `message`, which needs no thread. [List plan feedback](https://docs.coderabbit.ai/api/reference/list-code-task-plan-comments.md) returns the open and resolved threads for one plan version, without deleted comments:

```bash curl theme={null}
curl --get "$CODERABBIT_API_HOST/v1/code/tasks/$TASK_ID/plan/comments" \
  --header "x-coderabbitai-api-key: $CODERABBIT_API_KEY" \
  --data-urlencode "version=$PLAN_VERSION" \
  --data-urlencode "sha256=$PLAN_SHA256"
```

```bash CLI theme={null}
coderabbit api request "/code/tasks/$TASK_ID/plan/comments?version=$PLAN_VERSION&sha256=$PLAN_SHA256"
```

Each thread has an `id`, a `status` of `open` or `resolved`, a `location.quote` with the plan text it's about, and its `comments`, each with its own `id`, `text`, and `author`. Thread actions use the thread `id`; editing and deleting use the comment `id`:

| Action | Operation | Path ID | Body |
| - | - | - | - |
| Reply | [Reply to a thread](https://docs.coderabbit.ai/api/reference/reply-code-task-plan-comment-thread.md) | Thread | `version`, `sha256`, `text` |
| Resolve | [Resolve a thread](https://docs.coderabbit.ai/api/reference/resolve-code-task-plan-comment-thread.md) | Thread | `version`, `sha256` |
| Reopen | [Reopen a thread](https://docs.coderabbit.ai/api/reference/reopen-code-task-plan-comment-thread.md) | Thread | `version`, `sha256` |
| Replace your comment | [Replace a comment](https://docs.coderabbit.ai/api/reference/replace-code-task-plan-comment.md) | Comment | `version`, `sha256`, the complete new `text` |
| Delete your comment | [Delete a comment](https://docs.coderabbit.ai/api/reference/delete-code-task-plan-comment.md) | Comment | None; send `version` and `sha256` as query parameters |

For example, to reply to a thread and then resolve it, build both request bodies from `plan.json`, which you saved when you read the plan, then send them:

```bash theme={null}
jq --arg text 'Covered in step 3.' '{version, sha256, text: $text}' plan.json > reply.json
jq '{version, sha256}' plan.json > plan-version.json
```

```bash curl theme={null}
curl "$CODERABBIT_API_HOST/v1/code/tasks/$TASK_ID/plan/comments/threads/$THREAD_ID/replies" \
  --header "x-coderabbitai-api-key: $CODERABBIT_API_KEY" \
  --header "Content-Type: application/json" \
  --data @reply.json

curl "$CODERABBIT_API_HOST/v1/code/tasks/$TASK_ID/plan/comments/threads/$THREAD_ID/resolve" \
  --header "x-coderabbitai-api-key: $CODERABBIT_API_KEY" \
  --header "Content-Type: application/json" \
  --data @plan-version.json
```

```bash CLI theme={null}
coderabbit api request "/code/tasks/$TASK_ID/plan/comments/threads/$THREAD_ID/replies" --input reply.json
coderabbit api request "/code/tasks/$TASK_ID/plan/comments/threads/$THREAD_ID/resolve" --input plan-version.json
```

A reply returns `201` with the new `comment_id` and the updated feedback. Keep these rules in mind:

* Replying doesn't reopen a resolved thread, and resolving a thread doesn't approve the plan or start implementation.
* The API doesn't limit resolving to a thread's author, so a key can resolve threads that other people started. That closes their feedback without their agreement, so a script should resolve only threads it replied to and use Revise for the rest.
* Only a comment's author can replace or delete it. A replacement keeps the mentions whose tokens are still in the new text.
* Replies have no retry key. If a reply times out, list the feedback before you send it again, so you don't post it twice.

> [!CAUTION]
>
> Deleting the first comment of a thread deletes the whole thread, including other people's replies. Deleting a reply removes only that reply.

## 5. Approve, revise, or implement the plan

These calls finish the plan review. They're separate calls: approving a plan doesn't start implementation, and implementing doesn't require an approval.

* **Approve.** [Set the plan approval](https://docs.coderabbit.ai/api/reference/set-code-task-plan-approval.md) (`PUT`) with `version`, `sha256`, and `approved: true`. Send `approved: false` to withdraw your approval. The plan's author is the person who created the task: they can't approve their own plan and get `403 forbidden`, so send the approval with another person's key. See [Review a plan](https://docs.coderabbit.ai/code/work-with-a-task.md#review-a-plan).
* **Revise.** [Request a revision](https://docs.coderabbit.ai/api/reference/revise-code-task-plan.md) with your feedback as `message` and a `client_operation_id`. When the revision finishes, the task's `plan_version` increases; read the new plan from [step 3](#3-read-the-plan).
* **Implement.** [Implement the plan](https://docs.coderabbit.ai/api/reference/implement-code-task-plan.md) with the `version` and a `client_operation_id`. While any feedback thread on that version is open, including a thread a person started, the call returns `409 conflict`; resolve the threads or revise the plan first. CodeRabbit implements each plan version once, so repeating the call for the same version doesn't queue the work twice.

Build the bodies from `plan.json`:

```bash theme={null}
jq '{version, sha256, approved: true}' plan.json > approval.json
jq --arg op "implement-$TASK_ID-$PLAN_VERSION" '{version, client_operation_id: $op}' plan.json > implement.json
```

To approve the plan:

```bash curl theme={null}
curl --request PUT "$CODERABBIT_API_HOST/v1/code/tasks/$TASK_ID/plan/approval" \
  --header "x-coderabbitai-api-key: $CODERABBIT_API_KEY" \
  --header "Content-Type: application/json" \
  --data @approval.json
```

```bash CLI theme={null}
coderabbit api request -X PUT "/code/tasks/$TASK_ID/plan/approval" --input approval.json
```

The response is the plan with its updated `approvals`. To implement it:

```bash curl theme={null}
curl "$CODERABBIT_API_HOST/v1/code/tasks/$TASK_ID/plan/implementation" \
  --header "x-coderabbitai-api-key: $CODERABBIT_API_KEY" \
  --header "Content-Type: application/json" \
  --data @implement.json
```

```bash CLI theme={null}
coderabbit api request "/code/tasks/$TASK_ID/plan/implementation" --input implement.json
```

Revision and implementation return `202` when CodeRabbit accepts them. Follow the task from [step 2](#2-follow-the-task) until it reaches `plan_ready` again or `patch_ready`.

## 6. Deliver the patch

When the task reaches `patch_ready`, read the proposed patch with [Get the patch](https://docs.coderabbit.ai/api/reference/get-code-task-patch.md). `patch.patch` holds the unified diff. `patch` is `null` when the task has no patch, and `preview_status` is `too_large` when the diff is too large to return; review it on the task page instead.

Then [deliver the patch](https://docs.coderabbit.ai/api/reference/deliver-code-task.md). `delivery_mode` chooses how it lands:

| `delivery_mode` | What happens |
| - | - |
| `commit_to_pr_branch` | Commits the patch to the branch of the task's pull request. |
| `stacked_pr` | Pushes the patch to a new branch and opens a pull request. |

Without `delivery_mode`, CodeRabbit commits to the task's pull request when it has one, and opens a new pull request otherwise. A new pull request opens against the task's working branch, as [Deliver a task's changes](https://docs.coderabbit.ai/code/deliver-changes.md#choose-how-changes-land) explains, and the API has no field for its title or body. That page also covers both modes and who the commits are attributed to.

```bash theme={null}
echo '{"delivery_mode": "stacked_pr"}' > delivery.json
```

```bash curl theme={null}
curl "$CODERABBIT_API_HOST/v1/code/tasks/$TASK_ID/delivery" \
  --header "x-coderabbitai-api-key: $CODERABBIT_API_KEY" \
  --header "Content-Type: application/json" \
  --data @delivery.json
```

```bash CLI theme={null}
coderabbit api request "/code/tasks/$TASK_ID/delivery" --input delivery.json
```

A `202` response means CodeRabbit accepted the delivery. Poll the task until `pull_request_url` is set or `status` reports a problem.

Delivery pushes with the key owner's own GitHub authorization, which they connect in the CodeRabbit app. If it's missing or expired, delivery returns `401 unauthenticated` even though the API key is valid; reconnect GitHub in the app and deliver again. Branch protections still apply; see [When delivery is blocked](https://docs.coderabbit.ai/code/deliver-changes.md#when-delivery-is-blocked).

Delivery has no retry key. If a request times out, read the task and the pull request before you send it again.

## 7. Turn on Autofix

[Autofix](https://docs.coderabbit.ai/code/deliver-changes.md#autofix) publishes a task's work and keeps fixing review findings, failing checks, and merge conflicts on its pull request. [Get Autofix status](https://docs.coderabbit.ai/api/reference/get-code-autofix.md) takes a `target`, either a task or a pull request:

```bash curl theme={null}
curl --get "$CODERABBIT_API_HOST/v1/code/autofix" \
  --header "x-coderabbitai-api-key: $CODERABBIT_API_KEY" \
  --data-urlencode "target[type]=task" \
  --data-urlencode "target[taskId]=$TASK_ID"
```

```bash CLI theme={null}
coderabbit api request "/code/autofix?target[type]=task&target[taskId]=$TASK_ID"
```

For a pull request, use `target[type]=pull_request` with `target[repoId]` and `target[prNumber]`. The response says whether Autofix is `available` for the target. `watch` is `null` when Autofix isn't set up for the target; otherwise it reports `enabled`, `state`, `prUrl`, and a `reason` when there is one.

To change it, [send an Autofix command](https://docs.coderabbit.ai/api/reference/set-code-autofix.md) with the same `target` and an `action`: `enable`, `disable`, `resume`, or `recover`. `recover` also takes the `deliveryConflict` object from the status response.

```json autofix.json theme={null}
{
  "target": { "type": "task", "taskId": "TASK_ID" },
  "action": "enable"
}
```

> [!WARNING]
>
> Enabling Autofix authorizes CodeRabbit to publish changes and follow-up fixes without approving each patch. Repository permissions and branch protections still apply.

## 8. Request a review of the delivered pull request

When delivery sets `pull_request_url` (for example `https://github.com/acme/api/pull/42`), the pull request number is its last path segment, and the repository ID is the task's `repository_id`. Read both from [Get a task](https://docs.coderabbit.ai/api/reference/get-code-task.md):

```bash theme={null}
TASK=$(curl -sS "$CODERABBIT_API_HOST/v1/code/tasks/$TASK_ID" \
  --header "x-coderabbitai-api-key: $CODERABBIT_API_KEY")
REPOSITORY_ID=$(jq -r '.repository_id' <<<"$TASK")
PR_NUMBER=$(jq -r '.pull_request_url | split("/") | last' <<<"$TASK")
```

Read the [review status](https://docs.coderabbit.ai/api/guides/pull-request-reviews.md#4-follow-the-review-status) of that pull request first, and request a review only when the current head has none running or completed. A review request needs an agentic key; see [Authentication](https://docs.coderabbit.ai/api/authentication.md#which-keys-each-operation-accepts).

```bash theme={null}
curl "$CODERABBIT_API_HOST/v1/repositories/$REPOSITORY_ID/pull-requests/$PR_NUMBER/review" \
  --header "x-coderabbitai-api-key: $CODERABBIT_API_KEY" \
  --header "Content-Type: application/json" \
  --data '{}'
```

The [pull request reviews guide](https://docs.coderabbit.ai/api/guides/pull-request-reviews.md#3-request-a-review) covers the request, the status values, and what to do when `review` is `null`.

## Run it unattended

One agentic key can run every step of this flow. Approving a plan is the exception for tasks the key's own owner created, and a few steps need a person or the app:

| Step | Key |
| - | - |
| Create, follow, read the plan, send plan feedback, revise, implement, read the patch, deliver, Autofix | User or agentic key, acting as its owner |
| Approve the plan | User or agentic key owned by an account other than the task's creator, with access to the task |
| Request a review of the pull request | Agentic key |

Give the bot its own account as the key owner. An agentic key's owner needs a seat, and delivery uses that account's GitHub authorization, so the pull requests and commits are attributed to it; see [Who pushes, and who wrote it](https://docs.coderabbit.ai/code/deliver-changes.md#who-pushes-and-who-wrote-it). Leave `is_private` unset on tasks that another account must approve, because a private task is visible only to its author.

* **Feedback threads on a plan start in the app.** The API can reply to, resolve, and reopen threads, but can't start one. To send feedback from a script, revise the plan with a `message`. List the feedback before you act on it.
* **Approval needs a second account.** The plan's author is the account that created the task, so a bot can't approve the plans of tasks it created; a key owned by another account, such as a second bot, can. Implementation doesn't check for an approval; if your process requires one, read the plan's `approvals` before you implement.
* **Delivery needs the key owner's GitHub authorization.** The key's owner connects GitHub in the CodeRabbit app, and CodeRabbit renews that authorization on its own. The API can't connect it: when it's missing or GitHub no longer accepts it, delivery returns `401 unauthenticated` until the owner reconnects GitHub in the app, so alert a person instead of retrying.
* **Some questions need the app.** Questions about the owner's personal connections or how to deliver the work return `412 precondition_failed`; a person answers them on the task page. See [Answer a question](#answer-a-question).
* **No webhooks.** The API doesn't notify you when a task changes. Poll [Get a task](https://docs.coderabbit.ai/api/reference/get-code-task.md), and stay within your [rate limit](https://docs.coderabbit.ai/api/conventions.md#rate-limits).
* **No lookup by `client_request_id`.** Tasks don't return it, and [List tasks](https://docs.coderabbit.ai/api/reference/list-code-tasks.md) can't filter by it. To find a task after a crash, send the same create request again.
* **No GitHub issue link, and no pull request title or body.** A task has no field for a GitHub issue, and delivery takes only `delivery_mode`, so the pull request can't say `Fixes #123`. Put everything the agent needs from the issue in `instructions`, and edit the pull request on GitHub afterward.

## Retry safely

Some calls take a key that makes a retry safe; others need a read first.

| Call | How to retry |
| - | - |
| Create a task | Send the same `client_request_id`. You get the task already created, with `created: false`. |
| Follow-up, plan revision, implementation, answer | Send the same `client_operation_id`. CodeRabbit accepts the operation once. |
| Approve or withdraw approval | Send it again. A repeat leaves your approval as it is. |
| Resolve or reopen a thread | Send it again. The thread ends in the state you asked for. |
| Reply to plan feedback, deliver | No retry key. Read the feedback, or the task and its pull request, before you send the call again. |
| Request a review of the task's pull request | No retry key, and each request starts a review like a new push. Read the [review status](https://docs.coderabbit.ai/api/guides/pull-request-reviews.md#4-follow-the-review-status) first, and request again only when no review of the current head is running or completed. |

CodeRabbit remembers a `client_request_id` for as long as the task exists, archived or not, and matches it per key owner and repository. It doesn't compare the rest of the body, so the same ID with new instructions returns the first task. Use a new ID for each new task, for example by adding an attempt number.

## Handle errors

All errors use the error format described in [Errors](https://docs.coderabbit.ai/api/conventions.md#errors). Error messages are generic, so use the status and the step you were on to find the cause:

| Response | Likely cause in this flow |
| - | - |
| `400 invalid_request` | The request body doesn't match the schema, or the task was started by an Automation, which these operations don't manage. |
| `401 unauthenticated` on delivery | The key owner's GitHub authorization for delivery is missing or expired. |
| `403 forbidden` | Coding Agent isn't enabled for the organization, the key owner can't change this task, or the task's creator tried to approve its plan. |
| `insufficient_scope` (MCP) | The MCP connection lacks the scope that the error names, such as `code:write`. Add it; see [MCP troubleshooting](https://docs.coderabbit.ai/api/mcp.md#troubleshooting). |
| `404 not_found` | The task doesn't exist or isn't visible to the key owner, or a turn is too old to read. |
| `409 conflict` | `version` and `sha256` don't match the current plan, or a feedback thread is still open when you implement. |
| `412 precondition_failed` | The prompt has to be answered in the app, or billing doesn't allow new Coding Agent work. |

## What's next

> [card] [Request and read reviews](https://docs.coderabbit.ai/api/guides/pull-request-reviews.md)
>
> Request a CodeRabbit review of the pull request your task opened and read the results.

> [card] [Work with a running task](https://docs.coderabbit.ai/code/work-with-a-task.md)
>
> See how the same task looks on its task page, where people can steer it and review its plan.

> [card] [Connect an MCP client](https://docs.coderabbit.ai/api/mcp.md)
>
> Connect an AI agent to CodeRabbit and call these operations as MCP tools.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.