starred/mailpit

Fork 0

mirror of https://github.com/axllent/mailpit.git synced 2026-04-26 08:45:54 +03:00

[GH-ISSUE #445] [feature-request] Advanced webhooks #287

New issue

Closed

opened 2026-03-15 13:41:56 +03:00 by kerem · 6 comments

kerem commented

2026-03-15 13:41:56 +03:00

Owner

Originally created by @baiomys on GitHub (Feb 16, 2025).
Original GitHub issue: https://github.com/axllent/mailpit/issues/445

Hi.

Please consider enhancing webhooks to be more Telegram style:

Setting/removing using API call
Implementing 10-30 minute queue for not acknowledged webhook calls, repeating every minute (possibility to enable/disable entire queue and adjust time/interval limits)

https://core.telegram.org/bots/api#setwebhook

Thanks in advance!

Originally created by @baiomys on GitHub (Feb 16, 2025). Original GitHub issue: https://github.com/axllent/mailpit/issues/445 Hi. Please consider enhancing webhooks to be more Telegram style: 1. Setting/removing using API call 2. Implementing 10-30 minute queue for not acknowledged webhook calls, repeating every minute (possibility to enable/disable entire queue and adjust time/interval limits) https://core.telegram.org/bots/api#setwebhook Thanks in advance!

kerem closed this issue

2026-03-15 13:42:02 +03:00

kerem commented

2026-03-15 13:42:08 +03:00

Author

Owner

@axllent commented on GitHub (Feb 16, 2025):

No, I'm sorry but I must decline this request. It would require a considerable amount of work to implement & maintain, including webhook message storage, queueing, scheduling, failure handling/retries, flexible configuration via new API endpoints etc. This is all functionality which falls completely out of scope of Mailpit.

What you are describing is functionality which should be part of your own application as it is very specific to your personal project.

@axllent commented on GitHub (Feb 16, 2025): No, I'm sorry but I must decline this request. It would require a considerable amount of work to implement & maintain, including webhook message storage, queueing, scheduling, failure handling/retries, flexible configuration via new API endpoints etc. This is all functionality which falls **completely out of scope** of Mailpit. What you are describing is functionality which should be part of your own application as it is very specific to your personal project.

kerem commented

2026-03-15 13:42:14 +03:00

Author

Owner

@baiomys commented on GitHub (Feb 16, 2025):

Webhook logic cannot be implemented on client side.
It will require database polling.

@baiomys commented on GitHub (Feb 16, 2025): Webhook logic cannot be implemented on client side. It will require database polling.

kerem commented

2026-03-15 13:42:19 +03:00

Author

Owner

@axllent commented on GitHub (Feb 16, 2025):

What you need is a message broker of sorts, and by that I mean an application that sits in-between Mailpit and Telegram and handles that kind of logic the way you want (plus everything else you need, or are going to need).

What you are currently doing is trying to integrate Mailpit directly with Telegram, meaning that if Telegram can't handle your logic, then it has to be in Mailpit. The issue is that you're asking me to add this whole piece of functionality into Mailpit to suit your app, but that functionality doesn't align with the purpose of Mailpit, it means I have to do all the work, and it is of little benefit to anyone other than yourself.

There are a few ways you can get the messages from Mailpit, polling is one way (and there is nothing wrong with that as it is fast and very low CPU). There is also a websocket in Mailpit which broadcasts new messages, although that is not part of the official API as it is intended for the web browser (so it is not documented). Your application could also just receive the current webhooks from Mailpit, and then pass them on to Telegram (including those features you are requesting). Once you have your application then you can do whatever you like.

@axllent commented on GitHub (Feb 16, 2025): What you need is a message broker of sorts, and by that I mean an application that sits in-between Mailpit and Telegram and handles that kind of logic the way you want (plus everything else you need, or are going to need). What you are currently doing is trying to integrate Mailpit directly with Telegram, meaning that if Telegram can't handle your logic, then it has to be in Mailpit. The issue is that you're asking me to add this whole piece of functionality into Mailpit to suit your app, but that functionality doesn't align with the purpose of Mailpit, it means I have to do all the work, and it is of little benefit to anyone other than yourself. There are a few ways you can get the messages from Mailpit, polling is one way (and there is nothing wrong with that as it is fast and very low CPU). There is also a websocket in Mailpit which broadcasts new messages, although that is not part of the official API as it is intended for the web browser (so it is not documented). Your application could also just receive the current webhooks from Mailpit, and then pass them on to Telegram (including those features you are requesting). Once you have your application then you can do whatever you like.

kerem commented

2026-03-15 13:42:24 +03:00

Author

Owner

@baiomys commented on GitHub (Feb 16, 2025):

You completely misunderstood the idea.
Advanced webhooks needed to keep client app informed about all new messages arrived in mailpit while client was unable to process webhooks (down). API hook assignment needed to quickly switch all pits to another core IP without restart.

Telegram is just an example of decent webhook API to look at.

@baiomys commented on GitHub (Feb 16, 2025): You completely misunderstood the idea. Advanced webhooks needed to keep client app informed about all new messages arrived in mailpit while client was unable to process webhooks (down). API hook assignment needed to quickly switch all pits to another core IP without restart. Telegram is just an example of decent webhook API to look at.

kerem commented

2026-03-15 13:42:29 +03:00

Author

Owner

@axllent commented on GitHub (Feb 16, 2025):

I actually understand you 100%, but I'm saying that in order to do that, I have to do a lot of work and add a lot of functionality to Mailpit. Whilst I am always open to improving Mailpit, sending a webhook isn't an important feature for what Mailpit is intended for, not to mention an API so change/update webhook configuration.

Your application logic (currently) relies entirely on a push from Mailpit, and that is weak if things break. You need something in-between to resume activity when things break - that is what I am saying.

Maybe take a look at something like https://n8n.io/ - as I sense you may not be in a position to write your own application. It's free (self hosted) and has a lot of features, so maybe it can be the message broker (I'm not sure).

@axllent commented on GitHub (Feb 16, 2025): I actually understand you 100%, but I'm saying that in order to do that, I have to do a lot of work and add a lot of functionality to Mailpit. Whilst I am always open to improving Mailpit, sending a webhook isn't an important feature for what Mailpit is intended for, not to mention an API so change/update webhook configuration. Your application logic (currently) relies entirely on a push from Mailpit, and that is weak if things break. You need something in-between to resume activity when things break - that is what I am saying. Maybe take a look at something like https://n8n.io/ - as I sense you may not be in a position to write your own application. It's free (self hosted) and has a lot of features, so maybe it can be the message broker (I'm not sure).

kerem commented

2026-03-15 13:42:34 +03:00

Author

Owner

@baiomys commented on GitHub (Feb 16, 2025):

Ok. Thanks for suggestions.
It would be wiser to implement watchdog script, which will instantly kill all mailpit instances if core dies.
Thus no messages will be lost.

@baiomys commented on GitHub (Feb 16, 2025): Ok. Thanks for suggestions. It would be wiser to implement watchdog script, which will instantly kill all mailpit instances if core dies. Thus no messages will be lost.