> For the complete documentation index, see [llms.txt](https://docs.stackai.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stackai.com/technical-reference/workflow-execution/paused-runs-human-input-and-resumption.md).

# Paused Runs, Human Input, and Resumption

A paused run waits for a person’s response. Resume that run instead of starting a second workflow so the decision stays attached to the original execution.

![Resume the existing run](https://1957915746-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FSQ1Sgy933krTyK0S4JpP%2Fuploads%2F8myK4ekXuUl124cVxgXJ%2Fpaused-runs-human-input-and-resumption.png?alt=media)

Obtain the person’s response and send it with the token issued for that pause. Keep tokens out of logs and frontend events. A 202 response accepts resumption; continue checking the run state.

<details>

<summary>Copy the example</summary>

```http
POST /v2/runs/{run_id}/resume
Content-Type: application/json

{
  "resume_token": "<token-from-the-paused-step>",
  "response": "<the-persons-response>"
}

# After acceptance, follow the same run ID.
GET /v2/runs/{run_id}
```

</details>

## Before you begin

Permission to read and resume the run, and the pending input returned by that run.

## Run resumption concepts

| Term           | Definition                                                                                                                                          |
| -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| Paused         | A run state that waits for a supported response before it can continue. Respond to the existing run instead of starting a new one.                  |
| Resume token   | A value supplied for a particular pending human-input request. Use it for that request only and keep it out of logs or public links.                |
| Response type  | The supported form of human input, such as text, approval, or choice. Match the submitted response to the pending request’s requirements.           |
| Run            | One execution of a project. Use its run ID to retrieve that execution’s state, input, output, and errors.                                           |
| Terminal state | A state indicating that a run has ended, such as succeeded, failed, or cancelled. Stop normal completion polling only after a final state is known. |

## Resume a paused run

1. Read the paused run and display the requested prompt and response options.
2. Submit its resume token and a response that matches the requested type.
3. Poll the same run until it pauses again or reaches a terminal state.

The existing run continues with the submitted response.

## Behavior and limitations

On v2 runs, pending input is exposed only when the caller has the required read and resume permissions. A 202 response acknowledges the resume request; it does not mean the workflow finished. Re-read state after a conflict. Do not log resume tokens or reuse them with another run.

### Resume a paused v2 run

Read `GET /v2/runs/{run_id}` and use the token from that run’s pending request. Submit the response to `POST /v2/runs/{run_id}/resume`:

```json
{
  "resume_token": "<token-from-pending-request>",
  "response": "<user-response>",
  "response_type": "text"
}
```

Use the response type required by the pending request. After a `202` response, read the same run again. If the run is no longer resumable, refresh its status instead of reusing the token.

## Related resources

[Execution Order and Node Dependencies](/technical-reference/workflow-execution/execution-order-and-node-dependencies.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.stackai.com/technical-reference/workflow-execution/paused-runs-human-input-and-resumption.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.