> ## 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.

# Webhook payload examples and variables

> Learn how to access inbound webhook payload data in Navis Ops workflows using trigger variables, with real examples from Stripe and other services.

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:

```json theme={null}
{
  "type": "payment_intent.succeeded",
  "data": {
    "object": {
      "id": "pi_3abc123",
      "amount": 9900,
      "currency": "usd",
      "customer": "cus_xyz"
    }
  }
}
```

Then in your workflow you can use:

| Variable                           | Value                      |
| ---------------------------------- | -------------------------- |
| `{{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:

```json theme={null}
{
  "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:

```json theme={null}
{
  "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.

```bash theme={null}
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.

<Warning>
  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.
</Warning>

## 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](https://webhook.site) — paste the temporary URL into your service, trigger a test event, and inspect the payload in the browser.
* [RequestBin](https://requestbin.com) — 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.

<Tip>
  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.
</Tip>

## Variable reference

| Variable                  | Description                                                            |
| ------------------------- | ---------------------------------------------------------------------- |
| `{{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.