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

# Widget Actions — overview

> The metadata + catalog endpoints that power the Widget Kit. Use these to configure widget instances dynamically and discover what protocols/tokens are supported.

These endpoints power the [Widget Kit](/widget/overview). They split into two families:

<CardGroup cols={2}>
  <Card title="Metadata generators" icon="cube">
    `POST /action/builders/*` — return a **JSON configuration** the widget renders as an Action (swap, transfer, cross-chain transfer, cross-chain bridge). Useful when you want your backend to dynamically configure widget instances per user, per region, or per offer.
  </Card>

  <Card title="Catalog" icon="book">
    `GET /action/directory` and `GET /action/tokens/{chain}/{protocol}` — discover what protocols and tokens are supported. Used internally by the widget to populate pickers; also useful for "what can my user do?" backend checks.
  </Card>
</CardGroup>

## What metadata generators actually return

Despite the URL prefix `builders/`, these endpoints **do not build transactions** — they return widget configuration JSON:

```json theme={null}
{
  "success": true,
  "metadata": {
    /* widget-renderable Action schema */
  }
}
```

The widget consumes the `metadata` payload to render the swap/transfer/bridge UI for the end user. Signing and broadcasting happen via the widget's signing flow, not via these endpoints.

## Why this isn't named "Builders" anymore

The URL prefix `/action/builders/*` predates the consolidation of ActionKit into Widget Kit. The endpoints generate **widget metadata**, not transaction calldata. We've kept the URL stable to avoid breaking existing integrations, but the docs label reflects what they actually do.

## Not covered here

* **Direct DEX swap execution** (`/action/execute/swap/*`) — these exist and use the modern passkey-stamped activity pattern, but they require a passkey ceremony in the browser on the `confirm` step. The API Reference documents only endpoints a backend can complete with the api key alone, so these live in the [Widget Kit](/widget/overview) — it owns the passkey UX end-to-end.
* **Lending / yield / earn** — not exposed via API at this time.
* **Approval flows** (ERC-20 allowances) — handled inside the widget. If you build your own UX from the metadata, you handle approvals yourself.

## Related

* [Widget Kit overview](/widget/overview) — the prebuilt UI consumer for these endpoints.
* [Widget SDK reference](/widget/sdk) — JS/TS methods for embedding.
* [Auth & Custody model](/shared/auth-model) — explains why end-user actions need a passkey on the device.