Problem
When Notifuse is deployed behind a private network (VPN, firewall, non-public DNS), AWS SNS cannot deliver webhook notifications to the HTTPS endpoint. This is common in enterprise environments where the application is not publicly accessible.
Currently the only option is to expose the webhook path publicly, which may not be allowed by network policy.
Proposal
Support an SNS to SQS consumption model as an alternative to the current HTTPS subscription approach. Notifuse would poll an SQS queue for delivery/bounce/complaint events instead of waiting for inbound HTTP pushes from SNS.
This would allow Notifuse to receive SES event notifications without any inbound network access.
Benefits
- Works in private/firewalled environments without exposing endpoints
- No inbound security surface to manage
- SQS provides built-in retry and dead-letter queue support
- Aligns with AWS best practices for decoupled architectures
Suggested approach
- During webhook registration, allow the user to choose between HTTPS subscription (current) or SQS subscription
- If SQS is chosen, create the queue and subscribe it to the SNS topic
- Add a background poller that consumes messages from the queue and processes them through the existing webhook handler logic
Problem
When Notifuse is deployed behind a private network (VPN, firewall, non-public DNS), AWS SNS cannot deliver webhook notifications to the HTTPS endpoint. This is common in enterprise environments where the application is not publicly accessible.
Currently the only option is to expose the webhook path publicly, which may not be allowed by network policy.
Proposal
Support an SNS to SQS consumption model as an alternative to the current HTTPS subscription approach. Notifuse would poll an SQS queue for delivery/bounce/complaint events instead of waiting for inbound HTTP pushes from SNS.
This would allow Notifuse to receive SES event notifications without any inbound network access.
Benefits
Suggested approach