Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.navisops.com/llms.txt

Use this file to discover all available pages before exploring further.

When an external service sends a POST request to your Navis Ops webhook endpoint, the request body becomes available as trigger variables throughout the workflow. You reference these variables using the {{trigger.*}} syntax, where the path after trigger. follows the JSON structure of the payload.

​
How trigger variables work

Every field in the inbound JSON body is accessible as a variable. If the payload is: 
{
  "type": "payment_intent.succeeded",
  "data": {
    "object": {
      "id": "pi_3abc123",
      "amount": 9900,
      "currency": "usd",
      "customer": "cus_xyz"
    }
  }
}
Then in your workflow you can use:
VariableValue
{{trigger.type}}payment_intent.succeeded
{{trigger.data.object.id}}pi_3abc123
{{trigger.data.object.amount}}9900
{{trigger.data.object.currency}}usd
{{trigger.data.object.customer}}cus_xyz
Use these variables in any node that supports text input — task titles, note content, notification messages, HTTP request bodies, and more.

​
Example: Stripe payment webhook

When a payment succeeds in Stripe, Stripe sends a payment_intent.succeeded event to your webhook URL. Here is the shape of that payload: 
{
  "type": "payment_intent.succeeded",
  "data": {
    "object": {
      "id": "pi_3abc123",
      "amount": 9900,
      "currency": "usd",
      "customer": "cus_xyz",
      "metadata": {
        "order_id": "order_987"
      }
    }
  }
}

​
Workflow example: create a follow-up task on payment

You want to automatically create a task to follow up with the customer whenever a payment succeeds. Workflow setup:
  1. Trigger: Webhook (your Stripe webhook URL, with x-webhook-secret matching the value in Stripe’s dashboard)
  2. Action: Create Task
    • Title: Follow up with {{trigger.data.object.customer}}
    • Description: Payment {{trigger.data.object.id}} for {{trigger.data.object.amount}} {{trigger.data.object.currency}} succeeded. Order: {{trigger.data.object.metadata.order_id}}
    • Project: (select your Customer Success project)
    • Priority: High
When a payment comes in, the task is created automatically with the customer ID and payment details pre-filled.

​
Example: GitHub webhook

When a pull request is opened on GitHub, GitHub sends an event like this: 
{
  "action": "opened",
  "pull_request": {
    "number": 42,
    "title": "Add dark mode support",
    "html_url": "https://github.com/your-org/your-repo/pull/42",
    "user": {
      "login": "contributor-name"
    }
  },
  "repository": {
    "name": "your-repo"
  }
}
In your workflow, you could create a task to review the PR:
  • Task title: Review PR #{{trigger.pull_request.number}}: {{trigger.pull_request.title}}
  • Description: Opened by {{trigger.pull_request.user.login}} in {{trigger.repository.name}}. Link: {{trigger.pull_request.html_url}}

​
Securing your webhook endpoint

Set a webhook secret in the Webhook trigger node panel. Then configure your external service to send that value in the x-webhook-secret header on every request. 
curl https://<your-supabase-project>.supabase.co/functions/v1/webhook-trigger?endpoint_id=<id> \
  -X POST \
  -H "Content-Type: application/json" \
  -H "x-webhook-secret: your-secret-value" \
  -d '{"event": "test", "data": {}}'
Navis Ops rejects requests where the x-webhook-secret header is missing or does not match the configured value. The request returns 403 Forbidden and the workflow does not run.
Store your webhook secret the same way you store other credentials — as an environment variable or in your secrets manager. Do not commit it to source code.

​
Tips for testing webhook integrations

Before wiring up a real service, use a tool to inspect the exact payload your service sends. This lets you figure out the variable paths before building the workflow. Recommended tools:
  • webhook.site — paste the temporary URL into your service, trigger a test event, and inspect the payload in the browser.
  • RequestBin — similar to webhook.site, useful for capturing and inspecting HTTP requests.
Testing workflow:
  1. Create a temporary endpoint on webhook.site.
  2. Paste it into your external service as the webhook destination.
  3. Trigger a test event from the service.
  4. Copy the payload from webhook.site.
  5. Use those field names and paths to set up your {{trigger.*}} variables in Navis Ops.
  6. Swap the webhook.site URL for your actual Navis Ops endpoint URL and enable the workflow.
Most services include a Send test event or Test webhook button in their webhook settings. Use this to trigger a sample payload without making a real transaction or event.

​
Variable reference

VariableDescription
{{trigger.*}}Any field from the inbound JSON payload, accessed by dot-notation path
{{trigger.endpoint_id}}The ID of the webhook endpoint that received the request
{{trigger.timestamp}}ISO 8601 timestamp of when Navis Ops received the request
{{trigger.method}}HTTP method of the inbound request (usually POST)
The endpoint_id, timestamp, and method fields are added by Navis Ops automatically. All other fields come from the request body.