Inxmail MCP

Get the Inxmail Commerce API entry point. Returns HAL+JSON with _links to all available resources (sendings, bounces, blocklist, blacklist, events, etc.). Use this to discover available endpoints or verify API connectivity. Read-only, no side effects.

Trigger a transactional email event, causing Inxmail to send an email to the recipient specified in the payload. This is a write operation — it dispatches an actual email. Use get_event_state with the returned transactionId to check delivery outcome. Provide a transactionId for deduplication within a 72-hour window. Returns the transaction ID and acceptance status.

Check the processing state of a previously triggered event. Use after trigger_event to verify whether the email was accepted, sent, bounced, or failed. Returns state details including any error information. Read-only.

List all configured transactional event types in Inxmail. Event types define the templates and triggers for transactional emails (e.g. order confirmation, password reset). Use this to discover available event type IDs before calling trigger_event. Returns paginated HAL+JSON with event type details. Read-only.

Get detailed configuration of a single event type by its ID. Returns the event type name, description, and configuration. Use this when you already have an event type ID and need its details; use list_event_types to discover available IDs. Read-only.

List transactional email sendings (event-triggered emails only, not mail relay). Use this to audit which transactional emails were sent, to whom, and when. Filter by recipient email, event type, customer ID, or date range. For mail relay sendings, use list_relay_sendings instead. For a comprehensive delivery report including bounces and reactions, use check_email_delivery. Returns paginated HAL+JSON with sending details. Read-only.

Get full details of a specific transactional email sending by its ID. Returns recipient, event type, timestamps, and delivery status. Use this when you have a specific sending ID from list_sendings or get_event_state. For mail relay sendings, use get_relay_sending instead. Read-only.

List recipient reactions (opens and clicks) for transactional emails. Use this to track engagement — who opened or clicked links in event-triggered emails. Filter by reaction type, recipient, event, sending, or date range. For mail relay reactions, use list_relay_reactions instead. Returns paginated HAL+JSON with reaction type, timestamp, and recipient details. Read-only.

List bounced transactional emails. Bounces indicate delivery failures — hardbounces mean the address is permanently invalid (auto-added to blocklist), softbounces are temporary failures (e.g. mailbox full). Use this to investigate delivery issues for event-triggered emails. For mail relay bounces, use list_relay_bounces instead. Returns paginated HAL+JSON with bounce type, email, reason, and timestamps. Read-only.

List feedback loop complaints for transactional emails. Complaints occur when recipients mark emails as spam via their email provider. Use this to identify recipients who reported transactional emails as unwanted. For mail relay complaints, use list_relay_complaints instead. Returns paginated HAL+JSON with complaint type, email, and timestamps. Read-only.

List email addresses automatically blocked due to hard bounces. The blocklist is managed by Inxmail — addresses are added automatically when a hardbounce occurs. Unlike the blacklist (manually managed), blocklist entries reflect delivery failures. Use get_blocklist_entry to check a specific email, or check_email_blocked for a combined check. Returns paginated HAL+JSON with email and block date. Read-only.

Check if a specific email is on the hard-bounce blocklist. Returns the block date and email if found, or a 'not blocked' response if the email is not on the blocklist. Use this for a single-email lookup; use list_blocklist to browse all entries; use check_email_blocked to check both blocklist and blacklist at once. Read-only.

Remove an email from the hard-bounce blocklist, allowing transactional emails to be sent to this address again. This is a write operation — use with caution, as the address previously caused a permanent delivery failure. The address may be re-added automatically if it bounces again. Returns empty response on success.

List email addresses that have been explicitly (manually) blacklisted. Unlike the blocklist (auto-populated from hard bounces), blacklist entries are added intentionally via add_to_blacklist. Blacklisted addresses cannot receive any emails. Use get_blacklist_entry to check a specific email, or check_email_blocked for a combined blocklist+blacklist check. Returns paginated HAL+JSON with email and block date. Read-only.

Check if a specific email is on the explicit blacklist. Returns the blacklist entry with block date if found, or a 'not blacklisted' response if absent. Use this for a single-email lookup; use list_blacklist to browse all entries; use check_email_blocked to check both blocklist and blacklist at once. Read-only.

Explicitly blacklist an email address, permanently preventing all future emails to this address. This is a write operation — the recipient will not receive any transactional or relay emails until removed via remove_from_blacklist. Use this for opt-out requests or compliance blocks. Returns the created blacklist entry.

Remove an email from the explicit blacklist, allowing emails to be sent to this address again. This is a write operation. Only removes from the blacklist (manual blocks) — if the address is also on the blocklist (hard bounces), use remove_from_blocklist as well. Returns empty response on success.

Comprehensive block check — queries both the blocklist (auto-blocked from hard bounces) and the blacklist (manually blocked) in a single call. Use this as the first step when investigating why an email isn't being delivered. Returns a summary with blocked status, which lists the email appears on, and the full entry details. Prefer this over separate get_blocklist_entry/get_blacklist_entry calls. Read-only.

Full delivery diagnostic for a specific email address. Aggregates block status (blocklist + blacklist), sendings, bounces (hard/soft), and reactions (opens/clicks) into a single report. Use this as the primary tool for investigating delivery issues — it replaces the need to call list_sendings, list_bounces, list_reactions, and check_email_blocked separately. Defaults to the last 30 days if no date range is specified. Read-only.

Send a fully composed RFC 5322 email via Inxmail's infrastructure. The message must be Base64-encoded and include all headers (From, To, Subject, MIME). This is a write operation — it dispatches a real email. Use this for custom one-off emails that don't fit an event type template. Returns the sending result.

List mail relay sendings — emails sent via Inxmail's SMTP relay (not event-triggered). Mail relay is used when your application sends emails through Inxmail as an SMTP gateway. Use list_sendings for event-triggered transactional emails instead. Filter by recipient, correlation IDs, or date range. Returns paginated HAL+JSON. Read-only.

Get full details of a specific mail relay sending by its ID. Returns recipient, timestamps, correlation IDs, and delivery status. Use this when you have a relay sending ID from list_relay_sendings. For event-triggered sendings, use get_sending instead. Read-only.

List recipient reactions (opens and clicks) for mail relay emails sent via SMTP relay. Use this to track engagement on relay-sent emails. For reactions on event-triggered transactional emails, use list_reactions instead. Filter by reaction type, recipient, relay sending ID, correlation IDs, or date range. Returns paginated HAL+JSON. Read-only.

List bounced mail relay emails. Hardbounces indicate permanent delivery failures; softbounces are temporary (e.g. mailbox full). Use this for relay-sent emails only; for event-triggered transactional bounces, use list_bounces instead. Filter by bounce type, recipient, relay sending ID, correlation IDs, or date range. Returns paginated HAL+JSON. Read-only.

List feedback loop complaints for mail relay emails. Complaints occur when recipients mark relay-sent emails as spam. Use this for relay emails only; for event-triggered transactional complaints, use list_complaints instead. Filter by complaint type, recipient, relay sending ID, correlation IDs, or date range. Returns paginated HAL+JSON. Read-only.

List delivery status records showing the final delivery outcome for sent emails. Use this for a high-level overview of delivery success/failure across all emails. For detailed per-recipient diagnostics, use check_email_delivery instead. Returns paginated HAL+JSON with delivery details. Read-only.

List system error log entries from Inxmail. Errors include API failures, rendering issues, and processing problems — not bounce/delivery errors (use list_bounces for those). Use this to diagnose server-side issues. Use get_error_log for full details of a specific entry, and mark_error_log_read to acknowledge it. Returns paginated HAL+JSON. Read-only.

Get full details of a specific error log entry by its ID. Returns the error message, timestamp, and context. Use this after finding an entry via list_error_logs. Use mark_error_log_read to acknowledge it after review. Read-only.

Mark an error log entry as read/acknowledged. This is a write operation that updates the entry's read status. Use this after reviewing an error via get_error_log to track which errors have been addressed. Returns empty response on success.