The Developer module is a REST API, available in JSON or XML, that gives programmatic access to almost everything the administration console can do by hand: configuration parameters for every module, stored email (junk, errors, sent items), account and user data (signatures, external accounts), mailbox contents and folders, and contacts/tasks/events from the Calendar and Mailbox modules.
The practical effect is that a mail server which is normally something you configure once through a GUI becomes something your own application can read from and write to at runtime — check a mailbox from a script, change a routing rule from your admin panel, or pull a user's signature into another system.
The module also has its own rule engine, the same one used for webhooks, which can now trigger a file export as well as (or instead of) an HTTP callback — writing a matching message straight to disk as MIME or plain text. See exporting matched email to EML or text files for that pattern in detail.
Most email-sending APIs (SendGrid, Postmark, Mailgun and similar) are built around one job: deliver transactional or marketing email, well, at scale. That is a different job from managing an entire mail server's configuration, stored mail, and mailbox data programmatically. The Developer module is closer to "give my application admin-level, scriptable control of the mail server itself" than "give my application a way to send an email."
Because it runs on infrastructure you host, there is no per-call metering to plan capacity around, and no third party in the data path handling message content — relevant if you send or process anything with GDPR or confidentiality implications. It is not a drop-in replacement for a sending API if all you need is "send a transactional email"; for that, plain SMTP relay is usually simpler — see sending email from a web application.
A few concrete patterns the API is designed for:
- Configuration as code. Push routing rules, blocklists, or account settings from your own deployment scripts instead of clicking through the admin console on every environment.
- Custom dashboards. Pull queue depth, quarantine counts, or per-account send/receive stats into your own internal ops dashboard rather than logging into the mail admin UI.
- Mailbox-aware applications. Read and manage mailbox contents, folders, contacts, tasks and calendar events from an application that needs email/collaboration data without embedding a full mail client.
- Provisioning automation. Create accounts, set signatures, and configure external account fetch (POP3/IMAP) as part of your own customer onboarding flow, if you run Hexamail as the backend for a multi-tenant product.
A few practical points worth knowing before you build against it:
- JSON or XML results — pick whichever fits your stack; JSON is the natural choice for JavaScript, PHP, Python and most modern backends.
- SSL support is available for the API connection; use it for anything beyond a local development box.
- Restrict access by IP and port at the API level, on top of whatever firewalling you already have, so the API surface is not reachable from anywhere that does not need it.
- Treat API credentials the same way you would a database connection string — a script or CI pipeline with API access to configuration is effectively an administrator.
The API is pull: your code asks for data or pushes a configuration change. For event-driven work — "tell my application the moment a matching email arrives" — combine it with webhooks, or with a file-drop action if the receiving system reads directories rather than HTTP, rather than polling the API on a loop. See building event-driven email workflows and exporting matched email to files for how these fit together in practice.
The Developer module ships as part of Hexamail Nexus, Hexamail Guard and Hexamail Server, and exposes a REST API over JSON or XML covering configuration, stored email, accounts, mailbox, contacts and calendar data, with SSL and IP/port restriction available. There is no separate per-call charge — access is included with your existing licence, which matters if you are building a feature that calls the API frequently.