Enhancement: Add Webhook Filtering Options for RECEIVE_WEBHOOK_URL

[AlimFreight]

🚀 Feature Request: Add Webhook Filtering Options for RECEIVE_WEBHOOK_URL

Currently, the RECEIVE_WEBHOOK_URL sends all received events (messages, status updates, typing indicators, read receipts, etc.) for all registered numbers to a single destination.

While this data can be filtered client-side (e.g., in n8n), implementing server-side filtering would save bandwidth and significantly simplify every receiving workflow.

I propose adding new environment variables to allow for server-side filtering of events pushed to the webhook.

---

1. Filtering by Event Type (Excluding Noise)

Goal: Allow users to stop receiving common high-volume, low-value events like typing indicators and read receipts.

Proposed Env Variable	Example Value	Description
WEBHOOK_FILTER_EVENT_TYPES	typingMessage,readReceipt	A comma-separated list of event types to EXCLUDE from the webhook payload (e.g., exclude typing indicators).

Justification:

• Efficiency: Events like typingMessage are frequent and noisy. Filtering these server-side reduces network traffic and processing load on the receiving application (like n8n).
• Clarity: It ensures automation workflows are only triggered by actual user-generated content (dataMessage) without needing a preliminary filtering step in every downstream tool.

---

2. Filtering by Receiving Account (Multi-Number Support)

Goal: Allow users running multiple registered Signal numbers in a single API instance to separate messages into distinct workflows.

Proposed Env Variable	Example Value	Description
WEBHOOK_RECEIVE_ONLY_FROM_NUMBER	+12345678900	If set, the webhook will only send events that were received by this specific registered account (params.account).

Justification:

• Workflow Separation: Users running multiple Signal accounts (+123... and +987...) in one container often need messages for each account to go to a separate destination (e.g., two different n8n webhooks).
• Scalability: Allowing separation at the source simplifies complex automation setups and improves reliability.

---

💡 Alternative Consideration for Developers

Instead of a single RECEIVE_WEBHOOK_URL, consider implementing a pattern where the receiving number is part of the webhook configuration, like this:

• New Env Variable Pattern: WEBHOOK_URL_<NUMBER>
• Example: WEBHOOK_URL_+12345678900=https://n8n.host/hook1

This would implicitly achieve the filtering for feature #2 without needing an extra filter environment variable.

Thank you for considering these enhancements! They would significantly improve the utility and performance of the webhook feature for automation users.