---
title: "Hookah"
url: "https://radix.wiki/developers/tools/hookah"
version: "1.3.0"
updated: 2026-08-15
last_verified: 2026-08-15
license: CC-BY-4.0
license_url: "https://creativecommons.org/licenses/by/4.0/"
---

# Hookah

|  |  |
| --- | --- |
| **Type** | Event Monitoring / Webhook Platform |
| **Network** | Radix Mainnet and Stokenet |
| **Service** | Live — [hookah.ing](https://hookah.ing), dashboard at [app.hookah.ing](https://app.hookah.ing) (checked 9 August 2026) |
| **Auth** | Radix ROLA — a wallet persona is the account |
| **SDK** | [hookah-sdk](https://www.npmjs.com/package/hookah-sdk) 1.0.0 (npm) |
| **Language** | TypeScript (pnpm + Turborepo monorepo) |
| **Repository** | MIT, published 5 July 2026 as an open-source snapshot |

## Overview

[Hookah](https://github.com/xstelea/hookah) is an open-source [Radix](/contents/tech/core-protocols/radix-engine) event-monitoring and webhook-delivery platform by [Alex Stelea](https://github.com/xstelea) (xStelea), a prolific author of Radix developer tooling. Developers authenticate with [Radix ROLA](/developers/frontend/03-rola-authentication), register on-ledger event triggers, and receive real-time webhook deliveries when matching events appear in the Radix transaction stream. The stated problem it removes is the one every dApp hits at the same moment: reacting to an on-chain event otherwise means [running dedicated nodes or polling a rate-limited API](https://hookah.ing/docs), writing stream-processing and filter logic, and building retrying webhook delivery — infrastructure that has nothing to do with the dApp.

The MIT-licensed repository and the hosted service are both active. [hookah.ing](https://hookah.ing) served its site, documentation and a live mainnet event stream on 9 August 2026, and the dashboard at [app.hookah.ing](https://app.hookah.ing) answered with the ROLA sign-in challenge — the two are separate deployments behind the same domain.

It also has a named production consumer, which is rarer for a one-author tool than a working demo is. [Notix](/ecosystem/notix), a real-time Radix notification service, credits ["Webhook services provided by Hookah"](https://notix.live) in its footer and links the dashboard at [app.hookah.ing](https://app.hookah.ing) (read 15 August 2026). The pairing is the architecture working as designed: a Radix account's state is something you have to _pull_ from the [Gateway](/contents/tech/core-protocols/radix-gateway-api), Hookah converts matching on-ledger events into an outbound POST, and Notix turns that POST into the notification a user actually receives — three layers, none of which has to run a node.

## Architecture

Hookah is a TypeScript monorepo (Turborepo + pnpm) with several components: a **Streamer** worker that follows Radix transactions and dispatches matching webhook deliveries; a **Dashboard** (Next.js) serving the web app, authentication, and tRPC/JSON-RPC endpoints; a Docusaurus documentation site; and a webhook test-server helper. It builds on the [Radix Gateway API](/contents/tech/core-protocols/radix-gateway-api) and the [radix-web3.js](/developers/tools/radix-web3-js) library, with PostgreSQL, Redis, and Drizzle ORM for storage.

The split between the two processes is where the reliability story sits. The dashboard owns writes and migrations; the streamer reads transaction pages from the Gateway, transforms the events, loads candidate triggers from a Redis registry, executes the matching webhooks, writes execution logs, and — per the repository's own description — **advances the stream checkpoint only after processing succeeds**. A crash mid-page therefore re-reads that page rather than skipping it, which trades a possible duplicate delivery for not silently losing an event. Application logic under `packages/api` is written with [Effect](https://effect.website/), the same design choice the author made across [radix-web3.js](/developers/tools/radix-web3-js).

## Triggers and the Webhook Payload

A webhook in Hookah is a destination — a URL, an optional name, and an optional header key/value pair used to authenticate the call at the receiving end. Triggers hang off it. Each trigger names an **emitter address** and an **event name**, and the event name must match what the component actually emits, character for character; the published [troubleshooting guide](https://hookah.ing/docs/troubleshooting) lists a mismatched event name and an inactive watcher as the two usual reasons a webhook stays silent.

When a trigger matches, the endpoint receives a POST whose body carries the transaction and the decoded events together:

```
{
  eventWatcherId: string;
  transactionId: string;
  events: {
    data: ProgrammaticScryptoSborValue;
    emitter: {
      globalEmitter: string;
      methodEmitter: string;
      outerEmitter: string;
    };
    eventName: string;
  }[];
}
```

The three-part emitter is the detail worth reading twice, because it is what makes a deposit alert workable. For a `DepositEvent`, `globalEmitter` is the account, `methodEmitter` is the internal vault the deposit landed in, and `outerEmitter` is the [resource address](/developers/scrypto/02-resources-and-nfts) — so the payload answers _who_, _where_ and _which token_ without a follow-up Gateway call. `data` arrives as programmatic SBOR, the same shape the [Gateway](/contents/tech/core-protocols/radix-gateway-api) returns, so an existing decoder works unchanged. Deliveries are recorded with response codes, error messages, retry attempts and timestamps, and the dashboard can fire a test POST before a real event ever matches.

## The SDK

Everything the dashboard does is reachable programmatically through [hookah-sdk](https://www.npmjs.com/package/hookah-sdk), published to npm at 1.0.0. Its authentication path is the interesting part: rather than driving a wallet, the SDK takes an Ed25519 keypair and a signer callback, builds a persona proof, and completes the same ROLA challenge the browser flow uses — `createEd25519KeyPair` and `createHookahSdk`, then `await sdk.auth()`. What comes back from `getTrpcClient()` is a typed [tRPC](https://trpc.io/) client over the same API surface, so `client.webhook.create.mutate({ url })` registers a webhook from a script or a CI job. A [JSON-RPC API](https://hookah.ing/docs/json-rpc-api) covers callers that are not TypeScript.

One constraint follows from the design and catches people locally: the API rejects `localhost` webhook URLs, so testing delivery end to end needs a public HTTPS receiver — the repository's own end-to-end suite reaches for ngrok, and skips those tests when no tunnel is configured.

## The Public Repository Is a Snapshot

What is on GitHub is not a running mirror of the service, and the distinction matters before cloning. Every commit on `main` dates from **5 July 2026** — six of them, all by the author, the first titled ["chore: initial open source snapshot"](https://github.com/xstelea/hookah/commits/main). The repository has been public since March 2025 but carries that single day of history.

The deployment has since moved past it. The site the snapshot builds is titled `HOOKAH :: MONITOR_THE_RADIX_NETWORK`; the page hookah.ing actually serves is titled "Webhooks for the Radix ledger", and it advertises capabilities the published documentation does not describe — field-level conditions on event contents, and a trigger that **messages a Telegram chat instead of calling an endpoint**. In the snapshot's own docs, conditional filtering is still listed as a [V1 roadmap item](https://hookah.ing/docs/roadmap) and Telegram appears only as the support chat. A clone therefore builds the July state, not what the hosted service runs today.

The usual caveats for a one-author tool apply: six commits, one contributor, one star, and no public issue tracker activity. The licence, at least, is unambiguous — an MIT `LICENSE` file sits in the repository root, which is more than can be said for some of the same author's other work (see [radix-web3.js](/developers/tools/radix-web3-js), where npm and the repository disagree).

## External Links

- [Hookah – hookah.ing](https://hookah.ing)
- [Documentation](https://hookah.ing/docs)
- [Dashboard – app.hookah.ing](https://app.hookah.ing)
- [Hookah – GitHub](https://github.com/xstelea/hookah)
- [hookah-sdk on npm](https://www.npmjs.com/package/hookah-sdk)
- [Alex Stelea (xStelea) – GitHub](https://github.com/xstelea)
- Wiki: [radix-web3.js](/developers/tools/radix-web3-js) – the same author's package suite, which Hookah builds on
- Wiki: [ROLA Authentication](/developers/frontend/03-rola-authentication)