My scenario is the following: we currently have an e-mail based customer support flow and wish to migrate to Zammad. However, getting a dedicated inbox for Zammad to watch over is currently difficult at the company for some technical reasons and for some organizational reasons. I’d much prefer a solution that would be workable for a single DevOps engineer to deploy and run. Therefore I use PostMark for email processing.
What I would like to see:
- I use Postmark’s inbound message stream feature to receive customer support e-mail, let’s say under support@mycompany.com.
- Postmark converts emails to support@mycompany.com to HTTP API calls/webhooks to a webservice of my choice. Unfortunately, they do not offer IMAP inboxes.
- The webservice of my choice receives Postmark’s webhook and feeds the e-mail somehow into Zammad (somehow).
- Zammad ingests the email like it would when using
Channel::Driver::MailStdin.new, automatically handling user creation, reply threading, customer agent notifications, CCs, etc.
What I see happening currently:
- I have Zammad running in a K8S environment. The K8S environment makes accessing the MailStdin channel driver from my webhook-receiving container difficult since that requires running a privileged command inside the running Zammad-Rails container. I can also not just run fetchmail since, again, this is using the/a containerized and stateless environment.
- Zammad does not seem to have an API that can ingest raw e-mails (or does it? ChatGPT tells me otherwise, but it might be hallucinating).
- I can use the API to create new tickets whenever a new e-mail arrives on my webhook as per e.g. Create ticket w/ email flow via API - #8 by gohai or Ticket API Injection. However, what’s unclear to me yet is how does this handle customer replies and threading/parsing/subjects/CCs/etc.? Won’t this method create a new ticket every time a customer replies to their Zammad-sent e-mail (causing the customers e-mail to go through my custom pipeline again)? I fear that my manual handling of the email contents will necessarily lead to some information loss that could be avoided when Zammad handled the e-mail as it would handle any other regular IMAP-ingested email.
- What I would basically like is an API endpoint that behaved exactly like the MailStdin channel, but over HTTP instead of a ruby command/console command.
I’m wondering if this is not possible with Zammad right now, or if I’m simply holding it wrong and it’s all very easy in the end. I’ve been digging all around the forums, but I’m not sure I’ve found a good solution yet. Most of the threads I found seem rather hacky and offer only workarounds that might break in edge cases.
Thank you for your reply!