[GH-ISSUE #201] Raw or parsed Data in Webhook calls #131

New issue

Closed

opened 2026-03-15 12:46:57 +03:00 by kerem · 4 comments

kerem commented

2026-03-15 12:46:57 +03:00

Owner

Originally created by @designerno1 on GitHub (Oct 30, 2023).
Original GitHub issue: https://github.com/axllent/mailpit/issues/201

Nice work.

A nice to have would be to have a option to send the raw data and or parsed data to the webhook

Including the attatchments

Originally created by @designerno1 on GitHub (Oct 30, 2023). Original GitHub issue: https://github.com/axllent/mailpit/issues/201 Nice work. A nice to have would be to have a option to send the raw data and or parsed data to the webhook Including the attatchments

kerem closed this issue

2026-03-15 12:47:03 +03:00

kerem commented

2026-03-15 12:47:09 +03:00

Author

Owner

@axllent commented on GitHub (Oct 31, 2023):

Thanks, I'm glad you like it :) Can you please explain what you are wanting to achieve with this additional data in the webhook calls exactly, as I think think this is much more of an API-related question? I'm reluctant to add anything is there that will drastically increase the network traffic.

Currently the webhook sends the message summary which includes the database ID of the new message. All the data you are after can then be fetched via the API once you have the message ID, for example:

Different people will have different requirements so this way you can just fetch what you need instead.

@axllent commented on GitHub (Oct 31, 2023): Thanks, I'm glad you like it :) Can you please explain what you are wanting to achieve with this additional data in the webhook calls exactly, as I think think this is much more of an API-related question? I'm reluctant to add anything is there that will drastically increase the network traffic. Currently the webhook sends the message summary which includes the database ID of the new message. All the data you are after can then be fetched via [the API](https://mailpit.axllent.org/docs/api-v1/) once you have the message ID, for example: - parsed data: http://mailpitserver:8025/api/v1/message/c715d5ce-1f91-4405-853b-f116be8b05e0 - raw email: http://mailpitserver:8025/api/v1/message/c715d5ce-1f91-4405-853b-f116be8b05e0/raw Different people will have different requirements so this way you can just fetch what you need instead.

kerem commented

2026-03-15 12:47:14 +03:00

Author

Owner

@designerno1 commented on GitHub (Oct 31, 2023):

Hi,

My Plan was to not do the api call to the server, instead trigger a symfony message with the webhook call and have all the raw data there to manipulate the message and resend it over a real smtp

@designerno1 commented on GitHub (Oct 31, 2023): Hi, My Plan was to not do the api call to the server, instead trigger a symfony message with the webhook call and have all the raw data there to manipulate the message and resend it over a real smtp

kerem commented

2026-03-15 12:47:19 +03:00

Author

Owner

@designerno1 commented on GitHub (Oct 31, 2023):

Also a cool optional feature would be to specify the webhook per user

@designerno1 commented on GitHub (Oct 31, 2023): Also a cool optional feature would be to specify the webhook per user

kerem commented

2026-03-15 12:47:24 +03:00

Author

Owner

@axllent commented on GitHub (Nov 1, 2023):

Hi @designerno1. Whilst I love getting feedback and suggestions, I am going to politely decline this request. There are a few reasons for this:

Based on what you are saying, it sounds like it is your intention to send messages directly to Mailpit (to record a copy?), but then rely on the webhook to trigger the sending of the actual message via another server. This in itself is prone to issues if the webhook fails to contact the website for any reason, or (unless you change the default) get rate limited when more than one email is received per second.
Mailpit already has SMTP relay functionality built in, meaning it can resend (manually, automatically, or via the API) messages via a preconfigured SMTP server after receiving them.
Mailpit already provides an API for those edge cases where others want to do something entirely custom (eg: manipulate the message, scheduled sending etc).

You are far better off building your system to poll the Mailpit API every minute or so, search/filter for new messages, and then do what you like with them. This will allow you to filter by whatever you like too (your last comment), and will also allow for some degree of network failure.

I hope this makes sense to you and that you can understand my reasoning here?

@axllent commented on GitHub (Nov 1, 2023): Hi @designerno1. Whilst I love getting feedback and suggestions, I am going to politely decline this request. There are a few reasons for this: 1. Based on what you are saying, it sounds like it is your intention to send messages directly to Mailpit (to record a copy?), but then rely on the webhook to trigger the sending of the actual message via another server. This in itself is prone to issues if the webhook fails to contact the website for any reason, or (unless you change the default) get rate limited when more than one email is received per second. 2. Mailpit already has [SMTP relay](https://mailpit.axllent.org/docs/configuration/smtp-relay/) functionality built in, meaning it can resend (manually, automatically, or via the API) messages via a preconfigured SMTP server after receiving them. 3. Mailpit already provides an API for those edge cases where others want to do something entirely custom (eg: manipulate the message, scheduled sending etc). You are far better off building your system to poll the Mailpit API every minute or so, search/filter for new messages, and then do what you like with them. This will allow you to filter by whatever you like too (your last comment), and will also allow for some degree of network failure. I hope this makes sense to you and that you can understand my reasoning here?