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

# Dify Plugin

> Use Actionbook inside Dify workflows and agents

<Note>
  The recommended way to get started is the [CLI](/guides/installation). The
  Dify plugin is an **optional, advanced** integration for teams building
  workflows and agents inside Dify.
</Note>

Use this option if you want verified selectors from Actionbook and cloud browser
automation directly in Dify.

## Why Use Actionbook in Dify

* Start from verified selectors and action manuals instead of guessing from raw
  HTML.
* Combine Actionbook search/get tools with live browser automation in one Dify
  workflow.
* Recover from selector drift by taking a fresh accessibility `snapshot` and
  continuing the run.

## Included Tools

| Tool                     | What it does                                            | Best for                                       |
| ------------------------ | ------------------------------------------------------- | ---------------------------------------------- |
| `search_actions`         | Search Actionbook for verified page areas and selectors | Finding the right element on a site            |
| `get_action_by_area_id`  | Fetch the full action manual for a selected area ID     | Getting precise CSS, XPath, and ARIA selectors |
| `browser_create_session` | Start a managed cloud browser session                   | Opening a browser before multi-step automation |
| `browser_operator`       | Navigate, click, fill, snapshot, and inspect pages      | Executing browser steps in a workflow          |
| `browser_stop_session`   | Stop the cloud browser session and release resources    | Cleanup at the end of a workflow               |

## Installation

Install the plugin directly from the official Dify Marketplace:

1. Open the [Actionbook plugin page](https://marketplace.dify.ai/plugin/actionbook/actionbook).
2. Click `Install`.
3. Enable the plugin in your Dify workspace.
4. Configure the plugin credentials before running browser workflows.

<Tip>
  The Marketplace page always provides the latest version, so you no longer
  need to download a GitHub release package or build a `.difypkg` manually.
</Tip>

## Credentials

### Actionbook API Key

* Optional for `search_actions` and `get_action_by_area_id`.
* Leave it empty to use the free tier, or add a key for higher quotas.
* Get a key from [actionbook.dev](https://actionbook.dev).

### Hyperbrowser API Key

* Required for `browser_create_session`, `browser_operator`, and
  `browser_stop_session`.
* Get a key from [Hyperbrowser](https://app.hyperbrowser.ai/).

## Recommended Workflow

The most reliable Dify flow is:

1. `search_actions` to find a relevant page area.
2. `get_action_by_area_id` to retrieve the full selector manual.
3. `browser_create_session` to start a cloud browser session.
4. `browser_operator` for navigation and page interaction.
5. `browser_stop_session` to release the session when the workflow finishes.

Example sequence:

```text theme={null}
search_actions(query="github login", domain="github.com")
get_action_by_area_id(area_id="github.com:login:email-input")

browser_create_session()

browser_operator(
  session_id="<session_id>",
  cdp_url="<ws_endpoint>",
  action="navigate",
  url="https://github.com/login"
)

browser_operator(
  session_id="<session_id>",
  cdp_url="<ws_endpoint>",
  action="snapshot"
)

browser_stop_session(session_id="<session_id>")
```

<Tip>
  Configure the Hyperbrowser API key in the plugin credentials first.
  `search_actions` and `get_action_by_area_id` are recommended for getting
  verified selectors first, but they are not a hard prerequisite for
  `browser_operator`.
</Tip>

How this maps to the current plugin behavior:

* `browser_operator` accepts either `session_id` or `cdp_url`; for multi-step
  workflows, pass both for the best recovery behavior.
* `browser_create_session` returns `ws_endpoint`, which should be passed to
  `browser_operator` as `cdp_url`.
* `snapshot` is a fallback step when selectors fail or page state changes, not
  a mandatory success-path step.
* `browser_stop_session` should be called after each browser workflow to release
  the remote session cleanly.

## Browser Operator Tips

* Use `fill` for form inputs when possible. It clears and writes the value in a
  single step.
* Use `snapshot` after navigation, after major page changes, or whenever a
  selector fails.
* Snapshot responses include accessibility refs like `[ref=e3]`; these are often
  the most reliable selectors for follow-up `click` and `fill` calls.
* Always call `browser_stop_session` at the end of the workflow to avoid
  unnecessary browser billing.

## Example Use Cases

* Search or filter content on dynamic web apps.
* Combine Actionbook search/get tools with browser automation for agentic task
  execution.
* Recover from selector drift by taking a fresh `snapshot` and continuing the
  workflow.