Document named webhook targets for per-path event routing

Filer-Notification-Webhook.md

@@ -145,11 +145,28 @@ path_prefixes = ["/important", "/data"]
 | `event_types` | array | No | all | create, update, delete, rename | Filter events by type |
 | `path_prefixes` | array | No | all | - | Filter events by path prefix |
 
-### One Endpoint, One Target
+### One Queue, Many Endpoints
 
-Only one notification target can be enabled at a time — if two sections (e.g. `[notification.webhook]` and `[notification.kafka]`) are both `enabled = true`, the filer fails at startup. The webhook target itself supports a single endpoint: exactly one `[notification.webhook]` block with one `endpoint`. Named sub-tables such as `[notification.webhook.my_service]` are not additional endpoints; they are ignored.
+Only one notification queue can be enabled at a time — if two top-level sections (e.g. `[notification.webhook]` and `[notification.kafka]`) are both `enabled = true`, the filer fails at startup.
 
-To route events to multiple services, point the webhook at one service that fans out, or use the Kafka/SQS/Pub-Sub targets and let each consumer subscribe. Use `event_types` and `path_prefixes` to narrow what the single endpoint receives.
+Within the webhook queue, `[notification.webhook]` defines the default endpoint and each `[notification.webhook.<name>]` subsection with `enabled = true` spins up an additional target with its own endpoint, filters, retry and worker settings. This lets events be routed to different services by path prefix or event type:
+
+```toml
+[notification.webhook]
+enabled = true
+endpoint = "https://audit.example.com/all-events"
+
+[notification.webhook.file_ingress]
+enabled = true
+endpoint = "https://ingress.example.com/hook"
+event_types = ["create"]
+path_prefixes = ["/buckets/uploads/data"]
+
+[notification.webhook.metadata_extractor]
+enabled = true
+endpoint = "https://metadata.example.com/hook"
+path_prefixes = ["/buckets/repository"]
+```
 
 ## Quick Test