docs(integrations): fix eight webhook URLs that no route serves

[RamanKharchee]

Summary

Eight webhook pages published a URL that no route serves. Six carried a _webhook suffix (/api/webhooks/pagerduty_webhook); two used a singular, unprefixed path (/webhook/dynatrace). Neither shape matches the route group in api/public_webhooks.go or the alternation in the app nginx sidecar, so the request falls through to location /, the Next.js app answers a 404 HTML page, and the alert never reaches the pipeline. It presents as an ingress bug.

The product has always been right — the integration modal builds the URL from its own endpoint map. Only customers who followed these pages were broken.

Page	Published	Actual route
PagerDuty	/api/webhooks/pagerduty_webhook	/api/webhooks/pagerduty
ZenDuty	/api/webhooks/zenduty_webhook	/api/webhooks/zenduty
Elasticsearch	/api/webhooks/elasticsearch_webhook	/api/webhooks/elasticsearch
OpenObserve	/api/webhooks/openobserve_webhook	/api/webhooks/openobserve
Azure Monitor	/api/webhooks/azure_monitor_webhook	/api/webhooks/azure-monitor
Splunk	/api/webhooks/splunk_webhook	/api/webhooks/splunk
Dynatrace	/webhook/dynatrace	/api/webhooks/dynatrace?token=…
SolarWinds	/webhook/solarwinds	/api/webhooks/solarwinds?token=…

The suffixed names are integration_types rows (V477, V675, V890), not routes — someone templated the pages from the internal type name.

Also on the PagerDuty page: Send Test Event sends pagey.ping, which the handler rejects with ErrEventNotSupported, so the delivery is recorded as skipped and answers 200 while creating no event. The page told readers to verify the integration with it. It now says what a green test event does and does not prove, and verification is a real incident.

How a reviewer confirms this

The content type of a plain GET tells you which process answered — no cluster access needed. text/plain is Gin, so the path is routed. text/html is the Next.js app, so nginx never matched.

for p in pagerduty zenduty elasticsearch openobserve azure-monitor splunk dynatrace solarwinds \
         pagerduty_webhook splunk_webhook; do
  printf "%-22s " "$p"
  curl -s -o /dev/null -w "%{http_code} %{content_type}\n" "https://dev.nudgebee.pollux.in/api/webhooks/$p"
done
curl -s -o /dev/null -w "%{content_type}\n" https://dev.nudgebee.pollux.in/webhook/dynatrace

Every corrected path answers 404 text/plain; every path this PR removes answers 404 text/html.

Run against dev, 2026-09-23

pagerduty              404 text/plain
zenduty                404 text/plain
elasticsearch          404 text/plain
openobserve            404 text/plain
azure-monitor          404 text/plain
splunk                 404 text/plain
dynatrace              404 text/plain
solarwinds             404 text/plain
pagerduty_webhook      404 text/html; charset=utf-8
splunk_webhook         404 text/html; charset=utf-8
/webhook/dynatrace     text/html; charset=utf-8

A POST to the corrected path with a bogus token reaches the handler and is rejected by it, not by the router:

$ curl -X POST -d '{"probe":true}' -H 'Content-Type: application/json' \
    'https://dev.nudgebee.pollux.in/api/webhooks/pagerduty?token=probe-invalid-token'
{"message":"webhook validation failed"}

Sources of truth: route group api-server/services/api/public_webhooks.go:508; sidecar alternation deploy/kubernetes/app/templates/nginx-config.yaml; UI endpoint map app/src/components/integrations/modal/IntegrationDynamicFormModal.jsx:1870 building the URL at line 2071.

Type of change

• Update to existing documentation

Checklist

• I ran npm run build locally and the site builds without errors
• I ran npm run lint locally and lint passes
• Internal links work; new external links open the correct page
• My commits are signed off (DCO — git commit -s)
• I read CONTRIBUTING.md

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request updates the documentation for multiple webhook integrations (including Azure Monitor, Dynatrace, Elasticsearch, OpenObserve, PagerDuty, SolarWinds, Splunk, and ZenDuty) to reflect the correct URL paths and query parameters, ensuring users do not encounter 404 errors. It also clarifies PagerDuty's test event behavior. The feedback suggests a clearer phrasing for a troubleshooting entry in the PagerDuty documentation.

[gemini-code-assist]

For improved clarity, consider rephrasing this resolution description. The current list of path requirements is a bit dense, and the phrasing '...and https' is slightly awkward.

Suggested change

	| Webhook URL returns a 404 HTML page | The path is wrong and the request is reaching the NudgeBee web app instead of the alert pipeline. The path is `/api/webhooks/pagerduty` — lowercase, no `_webhook` suffix, nothing after it, and `https`. Copy the URL from the integration rather than typing it. |
	| Webhook URL returns a 404 HTML page | The path is wrong, causing the request to go to the NudgeBee web app instead of the alert pipeline. The correct path is `/api/webhooks/pagerduty`. Ensure the URL uses `https`, is lowercase, and has no `_webhook` suffix. To avoid typos, copy the URL directly from the integration. |

[RamanKharchee]

Thanks — applied in 9911d8d, with one addition.

The suggested wording drops nothing after it, and that is a real failure mode rather than filler: /api/webhooks/pagerduty/<anything> falls through the sidecar's ^/api/webhooks/(…)/?$ alternation exactly like the _webhook suffix does, and lands on the web app.

$ curl -s -o /dev/null -w '%{http_code} %{content_type}\n' \
    https://dev.nudgebee.pollux.in/api/webhooks/pagerduty/abc
404 text/html; charset=utf-8

So the row now reads with your clearer structure and keeps that constraint:

The path is wrong, so the request is reaching the NudgeBee web app instead of the alert pipeline. The correct path is /api/webhooks/pagerduty. Check that the URL uses https, is lowercase, has no _webhook suffix, and has nothing after pagerduty except the ?token= query. To avoid typos, copy the URL directly from the integration.