Your 15-year-old helpdesk doesn't know what a webhook is. That's fine. Point it at imap.mailhooks.dev:993 and it starts receiving mail through the same infrastructure as the rest of your stack.
Every serious company has one: the internal tool, open-source helpdesk, or vendor product whose email-import code predates webhooks — and "we'll migrate it later" turned into five years.
osTicket, Request Tracker, Mantis, old Jira Service Desk, Spiceworks
Python imaplib workers, PHP imap_open() cron jobs, Java Mail apps, Power Automate flows
Barracuda, Proofpoint, Global Relay, custom e-discovery pipelines that ingest via IMAP
Legacy CRMs, DMS like Alfresco or OpenKM, ERPs with "email-to-case" polling, scan-to-mail devices
imap.mailhooks.dev*@yourdomain.comIf your tool is a Python script using imaplib, this is the diff. That's it.
- HOST = "mail.example.com" + HOST = "imap.mailhooks.dev" PORT = 993 - USER = "[email protected]" + USER = "*@yourdomain.com" - PASSWORD = os.environ["IMAP_PASSWORD"] + PASSWORD = os.environ["MAILHOOKS_API_KEY"] with imaplib.IMAP4_SSL(HOST, PORT) as mail: mail.login(USER, PASSWORD) # ... rest of the script is unchanged
Worked examples for Thunderbird, Node.js, and raw openssl s_client are in the setup guide.
SPF, DKIM, and DMARC verification runs on every incoming message. Results are attached to the email metadata.
Mint a dedicated IMAP-only key per downstream system. Rotate without coordinating with the vendor. Keep HTTP API access completely separate.
Your retention policy applies as normal. The same inbox is reachable from IMAP, the HTTP API, the dashboard, and webhooks — one source of truth.
No rewrite. No vendor ticket. Just a three-line config change and a better inbox behind it.