How to Integrate Nodora with Zapier

A Nodora rule emits a signal whenever a business condition you care about is met. You can deliver those signals to Zapier as webhook events and use them to start flows in Slack, Gmail, Notion, HubSpot, Google Sheets, Discord, and anything else Zapier connects to.

The rest of this post wires that path end to end: the rule that emits the signal, the Webhook action that POSTs it to Zapier, and the evaluate call in your app that sets the whole thing off.

The rule

The decision lives in the ruleset. Whenever the conditions are met, the rule emits a signal, that signal is the hook Zapier listens for.

For this example, imagine you want to fire a Zap whenever a high-value lead signs up so your sales team gets pinged in Slack and the contact lands in HubSpot:

signal HighValueLeadSignedUp(user_id, email, company, plan)

rule LeadQualification {
  is_business_email = !strings::ends_with(input.email, "@gmail.com")
                   && !strings::ends_with(input.email, "@yahoo.com")
                   && !strings::ends_with(input.email, "@outlook.com")

  is_paid_plan  = input.plan in ["pro", "max", "enterprise"]
  is_high_value = is_business_email && is_paid_plan

  out qualified = is_high_value

  emit HighValueLeadSignedUp(
    input.user_id,
    input.email,
    input.company,
    input.plan
  ) when is_high_value
}

Two pieces matter here. signal HighValueLeadSignedUp(...) declares the signal and the arguments it carries (this is the name you will pick from the dropdown when creating the action). emit ... when is_high_value is the gate: the webhook only fires for leads the rule actually flags.

Once the rule looks right, release it to the environment your application talks to (usually production). Actions only run against released rule versions, so a rule that lives only in draft will never trigger the webhook, no matter how many times you evaluate it.

Create the action

Now create the action that turns the emitted signal into an outbound HTTP request to Zapier.

The form has three fields you care about:

• Signal: pick HighValueLeadSignedUp from the dropdown. The dropdown is populated from the signals declared in your ruleset.
• Action: pick Webhook. This is what performs an HTTP request.
• Webhook URL: paste the Zapier Catch Hook URL from your Zap (it looks like https://hooks.zapier.com/hooks/catch/...). Custom headers are optional: add them here if your Zap or any intermediary requires auth, a tracing ID, etc.

Save the action. From this point on, every time the signal is emitted in the released environment, the platform will POST the signal payload to that Zapier URL.

Trigger the flow from JavaScript

The last piece is evaluating the rule from your application. The @nodora/client package handles fetching the released ruleset, evaluating it locally against the input, and routing emitted signals through the platform so configured actions run.

// app/lib/nodora.ts
import { NodoraClient } from "@nodora/client";

export const nodora = new NodoraClient({
  apiKey: process.env.NODORA_API_KEY!,
  env: "production",
  strategy: { type: "stale-while-revalidate", ttl: 60_000 },
});

export const leads = nodora.ruleset("Leads");

Then, in whichever code path runs after a new user signs up, call evaluate with the lead's details:

import { leads } from "@/app/lib/nodora";

export async function onSignup(user: {
  id: string;
  email: string;
  company: string;
  plan: "free" | "pro" | "max" | "enterprise";
}) {
  const result = await leads.evaluate("LeadQualification", {
    user_id: user.id,
    email: user.email,
    company: user.company,
    plan: user.plan,
  });

  if (result.outputs.qualified) {
    console.log("lead qualified, Zapier webhook will fire");
  }
}

When a free-tier signup with a Gmail address comes in, the rule evaluates, the when guard rejects, no signal is emitted, and nothing reaches Zapier. When a pro-plan signup from @acme.com comes in, the rule evaluates, the when guard passes, HighValueLeadSignedUp is emitted, and the action fires a POST to the Catch Hook URL with the JSON payload. Zapier picks it up and runs the rest of the workflow: a Slack message, a HubSpot contact, whatever you wired up on their side.

Why this split works

The split between the rule, the action, and the Zap keeps each layer doing one thing:

• The rule owns the definition of "what counts as a high-value lead." Tightening or loosening the criteria is a rule edit and a rule release: no code deploy, no Zap rebuild.
• The action owns the transport. Swapping Zapier for n8n, or a direct internal webhook is a single edit on the action. The rule and the application code don't change.
• The Zap owns the downstream fan-out. Adding a "also create a Linear ticket" step is something a non-engineer can do without touching the platform at all.

That's the whole idea: a rule decides, a signal carries the decision, an action delivers it, and Zapier turns it into work in the rest of your stack.