Trigger conditions

Gate a webhook or WebSocket sink so it only fires on the events you care about.

Webhooks and WebSocket topics fire on every event that reaches them, which is rarely what you want. A Trigger Condition node sits in front of a sink and decides, per event, whether it fires.

How it works#

  1. Drag a Trigger Condition node onto the canvas.
  2. Give it a name and add the inputs your decision depends on — an amount, a mint, an authority.
  3. Wire the fields or transform outputs that supply those values into its inputs.
  4. Connect its gate output to the gate input on a webhook or WebSocket node.
  5. Open its code panel and write an evaluate function returning true to fire and false to drop.
condition.ts
export function evaluate(amount: u64, mint: string): bool {
  // Only notify on large USDC movements.
  if (mint != "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v") {
    return false;
  }
  return amount > 10_000_000_000; // 10,000 USDC (6 decimals)
}

What conditions can and cannot gate#

A condition gates triggers only. It has no effect on what is written to your database — table writes always happen for every matching event. If you want fewer rows, narrow what the indexer matches in the first place using the instruction and account discriminators, or filter in your own database afterwards.

Fan-out#

One condition can gate several sinks. Wire its gate output to a webhook and a WebSocket node and both are governed by the same rule, which is usually what you want when the same event should notify a backend and a UI at once.

Conditions are part of the sink#

The condition node is a convenience of the editor. When you save, its code and its inputs are folded into the sink it gates — the platform stores one trigger, not a trigger plus a separate condition.

This has one practical consequence worth knowing: a condition that is not connected to any sink does nothing at all and is not persisted as an independent object. Draw the gate wire.

Writing good conditions#

  • Return early. Cheap checks first — a mint comparison before an arithmetic one.
  • Be explicit about units.On-chain amounts are integers in the token's smallest unit. Comparing against a human-readable number without scaling is the most common bug here.
  • Keep it pure. The condition sees only the inputs you wired in — there is no clock, no network, and no memory of previous events. A condition cannot implement rate limiting or deduplication; do that in the service receiving the deliveries.