Webhook Logs & Troubleshooting Guide

🚧
Limited Preview: Webhook Triggers & Listener
Webhook Triggers and the Webhook Listener are currently in Limited Preview and may change without notice. Access is invite-only. Self-nomination form is here. Production use is approved but may be subject to interruptions or breaking changes.

This guide explains the new log types available for webhook triggers and how to use them to debug issues across the webhook trigger plugin lifecycle — from when Moveworks receives a webhook event to when your plugin executes.

The Webhook Trigger Plugin Lifecycle

When a webhook event is sent from an external app (e.g., Salesforce, ServiceNow, Workday), it passes through these main stages before your plugin runs:

[New] listener.webhook.trigger – Raw HTTP request received by Moveworks
[New] listener.webhook.processor.update – Event validated, transformed, and published (or rejected/debounced)
[New] listener.webhook.plugin.trigger – Plugins evaluated and triggered based on the event
[Existing] compound_action.trigger → compound_action.step.execute → action.* – Execution of the plugin’s actions.

New Log Types

`listener.webhook.trigger`

Purpose

Indicates that Moveworks has received a raw webhook request at your configured listener URL.

Log Body Example

"root": {
  "error_message": "",
  "headers": {
    "map": {
      "X-Github-Event": "issues",
      "X-Github-Delivery": "abc123",
      "Content-Type": "application/json",
      "User-Agent": "GitHub-Hookshot/12345"
    }
  },
  "http_method": "POST",
  "listener_metadata": {
    "request_id": "aaaaa-bbbbb-cccc",
    "listener_id": "xxxxx-yyyyy-zzzzz",
    "listener_name": "My_GitHub_Issue_Listener"
  },
  "parsed_body": {
    "action": "opened",
    "issue": {
      "id": 3290072009,
      "number": 11,
      "title": "New issue created",
      "state": "open",
      "html_url": "https://github.com/example-org/example-repo/issues/11"
    },
    "repository": {
      "id": 914634154,
      "name": "example-repo",
      "full_name": "example-org/example-repo",
      "html_url": "https://github.com/example-org/example-repo"
    },
    "sender": {
      "login": "octocat",
      "id": 3278918,
      "html_url": "https://github.com/octocat"
    }
  },
  "query_params": {},
  "raw_body": "<RAW_WEBHOOK_PAYLOAD>",
  "received_at": "2025-08-04T16:25:23Z"
}

Attribute Descriptions

listener_metadata – Metadata about the listener that received the request, including:
- listener_id – Unique ID of the listener.
- listener_name – Name of the listener as configured in Moveworks.
- request_id – Unique ID for this specific incoming request.
received_at – Timestamp when Moveworks received the event.
http_method – HTTP method used by the webhook request (e.g., POST).
headers – Key-value pairs sent in the webhook request headers by the provider (e.g., X-Github-Event, Content-Type).
query_params – Any query parameters included in the listener URL when the event was sent.
raw_body – The exact payload as received from the webhook provider, before parsing.
parsed_body – The parsed JSON object representing the webhook event payload.
error_message – Any error message if Moveworks could not read or validate the request. Empty string if successful.

What issues does this help debug?

Confirms whether Moveworks received the webhook at all.
Validates whether the request body was received and parsed correctly.
Shows the HTTP method, headers, and key payload fields for troubleshooting source system configuration.

If this log is missing, possible causes

Listener URL not correctly configured in your source system.
Payload could not be parsed (invalid JSON or unsupported format).
CRC challenge or handshake failure (if required by the provider).
Authentication failure or rate limiting (unsecured listeners are limited to 1 req / 10 sec; secure listeners have higher limits).
Signature verification failure (if signature validation is enabled).

`listener.webhook.processor.update`

Purpose

Indicates how Moveworks processed the raw webhook event after it was received, including whether it was published, rejected, or debounced.

Log Body Example

"root": {
  "error_message": "",
  "event_metadata": {
    "listener_metadata": {
      "request_id": "6adf6f8c-c076-4cba-8df6-bb25fb00a00d",
      "listener_id": "349c1220-aef5-43b1-9318-ebe53537c0fb",
      "listener_name": "My_GitHub_Issue_Listener"
    },
    "event_uuid": "d8vpkoKRVliC",
    "created_at": "2025-08-04T16:25:23.056654Z"
  },
  "event_payload": {
    "raw_body": "<RAW_WEBHOOK_PAYLOAD>",
    "parsed_body": {
      "action": "opened",
      "issue": {
        "id": 3290072009,
        "number": 11,
        "title": "New issue created",
        "state": "open",
        "html_url": "https://github.com/example-org/example-repo/issues/11"
      },
      "repository": {
        "id": 914634154,
        "name": "example-repo",
        "full_name": "example-org/example-repo",
        "html_url": "https://github.com/example-org/example-repo"
      },
      "sender": {
        "login": "octocat",
        "id": 3278918,
        "html_url": "https://github.com/octocat"
      }
    },
    "headers": {
      "X-Github-Event": "issues",
      "X-Github-Delivery": "abc123",
      "Content-Type": "application/json"
    }
  },
  "process_update": {
    "published_update": {
      "published_at": "2025-08-04T16:25:23.072620Z"
    }
  }
}

Attribute Descriptions

event_metadata – Metadata about the processed event:
- listener_metadata – The listener that received the original request.
- event_uuid – Unique ID assigned to this event.
- created_at – Time the event was first recorded by Moveworks.
event_payload – The event data after initial processing:
- raw_body – Exact webhook payload as received.
- parsed_body – JSON-parsed version of the webhook payload.
- headers – Request headers from the webhook provider.
error_message – Any processing error message (empty if processing succeeded).
process_update – Indicates the processing outcome:
- published_update – Event was published for further evaluation.
- failure_update – Event failed processing (includes failure_reason).
- debounced_update – Event dropped because a newer duplicate event was processed first.

What issues does this help debug?

Confirms that a webhook was successfully processed and published.
Identifies if the event failed processing and why.
Shows whether the event was dropped due to debounce rules.

If this log is missing, possible causes

Event was never received (listener.webhook.trigger missing).
Event failed at the listener stage due to auth, format, or CRC issues.
Internal processing failure before log emission (rare).

`listener.webhook.plugin.trigger`

Purpose

Indicates which plugins were evaluated for a processed webhook event, and whether they were successfully triggered, skipped, failed, or expired.

Log Body Example

"root": {
  "error_message": "",
  "event_metadata": {
    "listener_metadata": {
      "request_id": "12345678-abcd-1234-abcd-1234567890ab",
      "listener_id": "abcd1234-5678-90ab-cdef-1234567890ab",
      "listener_name": "My_Webhook_Listener"
    },
    "event_uuid": "evt-abc123xyz",
    "created_at": "2025-08-04T16:25:23.056654Z"
  },
  "expired": [],
  "failed_to_trigger": [],
  "skipped": [],
  "successfully_triggered": [
    "plugin-uuid-1234abcd5678efgh"
  ]
}

Attribute Descriptions

event_metadata – Metadata about the event:
- listener_metadata – Details of the listener that received the original webhook request.
- event_uuid – Unique ID assigned to the processed event.
- created_at – Timestamp when the event was first recorded.
successfully_triggered – List of plugin UUIDs that were triggered successfully.
failed_to_trigger – List of plugin UUIDs that matched conditions but failed to run.
skipped – List of plugin UUIDs skipped due to skip conditions.
expired – List of plugin UUIDs skipped because the event’s time-to-live (TTL) expired.
error_message – Any error message encountered during plugin evaluation (empty if successful).

What issues does this help debug?

Confirms which plugins were triggered for a given webhook event.
Identifies plugins that were skipped, failed, or expired before execution.
Helps trace why a particular plugin did not run.

If this log is missing, possible causes

The event did not pass the processing stage (listener.webhook.processor.update missing or failed).
No plugins matched the event’s trigger conditions.
Internal error prevented plugin evaluation (rare).

Troubleshooting by Scenario

Scenario A – My plugin never runs

Checklistener.webhook.trigger
- Missing? → Verify listener URL, auth, and payload format.
Checklistener.webhook.processor.update
- Was it published? If not, see failure_reason.
Checklistener.webhook.plugin.trigger
- Was your plugin in successfully_triggered?
- If skipped/failed: adjust trigger conditions or fix mapping.

Scenario B – My plugin starts but fails mid-run

From listener.webhook.plugin.trigger, find root_uuid or event_metadata.
Look at compound_action.trigger and compound_action.step.execute.
Identify which step failed (e.g., action.http 401 → fix credentials).

Scenario C – Events triggering inconsistently

Compare listener.webhook.trigger timestamps with any debounced_update entries.
If many events are debounced → reduce redundant sends from source or adjust debounce configuration.

Tips for Working with Webhook Logs

Use log_context in all logs to filter for a single event across stages.
Inconsistent UUIDs: Sometimes an event’s UUID is inconsistent across the webhook trigger plugin lifecycle. (Known issue: at plugin.trigger the UUID may switch). This is a known issue and a fix is in progress.
Secure your listener to increase rate limits and prevent throttling.

Reference: Full Lifecycle Flow

listener.webhook.trigger
   ↓
listener.webhook.processor.update
   ↓
listener.webhook.plugin.trigger
   ↓
compound_action.trigger
   ↓
compound_action.step.execute
   ↓
action.http / action.script / action.builtin

Updated about 11 hours ago