Email Delivery
Overview
Every transactional email UltraCart sends for an order is recorded against that order: when it went out, whether the receiving mail server accepted it, whether the customer opened it, whether they clicked a link, and why it failed if it never arrived. Email Delivery is the diagnostic that shows you that record for one order.
The tracking is automatic. There is no per-template setting to switch on, no separate reporting product, and no charge for it. If your account sends through an Email Sending Domain, UltraCart is already collecting delivery and engagement results for your receipts, shipment notices, and billing update emails, whether or not anyone has looked at them.
The record covers mail sent to the customer and mail sent to your own staff, so notifications to UltraCart users with order email notifications enabled appear alongside the customer's receipt.
What UltraCart records for each email
Each email on the order carries the subject line it was sent with, the address it went to, the time it was sent, and the outcome.
| Result | What it means |
|---|---|
| Delivered | The receiving mail server accepted the message. Acceptance by the mailbox provider is not proof the message reached the inbox rather than a spam folder. |
| Opened | A tracking pixel in the message loaded. Treat this as a soft signal rather than a fact. See What an open really tells you. |
| Clicked | The recipient followed a link in the message. This is the most trustworthy signal in the record, because image blocking cannot suppress it and automated prefetching does not produce it. |
| Bounced | The message was rejected. UltraCart stores the bounce type, a sub-type, and the diagnostic code the receiving server returned. |
| Skipped | UltraCart did not attempt the send at all, and stores the reason why. |
A bounce is either Permanent, meaning the address will not accept mail and further attempts will keep failing, or Transient, meaning the failure may clear on its own. A full mailbox is transient. An address that no longer exists is permanent. A sub-type of Suppressed means the send never reached the recipient's provider, because the address was already on a suppression list from earlier bounces.
Delivery records are kept for one year.
What an open really tells you
An open is recorded when a small tracking image in the message is fetched. Nothing guarantees the person fetching it is the customer, and nothing guarantees a customer who read the message fetched it at all. The number moves in both directions.
Opens are inflated by automated prefetching. Apple Mail Privacy Protection, on by default for Apple Mail users since iOS 15, fetches every tracking pixel through Apple's proxy as soon as a message arrives, whether or not the recipient ever looks at it. Corporate security gateways that scan links and images before delivery do the same thing. Both register as opens. On a consumer list, a large share of recorded opens can be machine fetches rather than people, and the reported open time and location belong to the proxy, not the customer.
Opens are suppressed by image blocking. Mail clients that do not load remote images by default record nothing, even when the customer read the message and acted on it.
The practical consequence is that an open rate is useful for spotting a change over time, and unreliable as a count of people. When you need to know whether customers actually engaged, particularly when the email exists to get someone to click through and fix a payment, judge it on clicks and on the outcome you cared about. A click is a deliberate act by a person, and it is the signal that correlates with the customer doing what the email asked.
Because Apple Mail Privacy Protection fetches pixels for messages that are never read, a rising open rate with a flat click rate usually reflects the mix of mail clients on your list rather than better engagement.
Why the screen can be empty
Email Delivery has data only when UltraCart controls the sending path. That means a configured Email Sending Domain in StoreFront Communications.
If your account sends through custom SMTP, UltraCart hands the message to your mail server and never sees what happened next, so no delivery records are captured. The trap is that a legacy SMTP entry under Main Menu → Configuration → Email Notifications → Email Addresses silently overrides an Email Sending Domain you have already set up and validated. The sending domain looks correct, the emails go out, and the diagnostic stays empty.
An empty Email Delivery screen usually means the sending type is still set to SMTP, not that the emails were never sent. Check the sending type slider under Configuration → Email Notifications → Email Addresses before concluding anything from a blank result.
To set up a sending domain, see Email Sending Domains.
Where to find it
Open the order on the Review Order screen, then use Possible Actions → Diagnostics → Email Delivery. The other entries in the same Diagnostics menu are described in Review Order.
Dispatch Logs does not cover these emails
Dispatch Logs in StoreFront Communications records messages sent by a flow or a campaign. Built-in transactional emails do not run through a flow, so they never produce a dispatch-log entry.
This matters because Dispatch Logs is the obvious place to look when a customer says an email never arrived, and for a receipt or a billing update email it will come back empty. That empty result is not evidence the message was not sent. Email Delivery on the order is the record for those messages, and Statistics likewise covers campaign and flow performance rather than transactional mail.
The same record for a subscription
The Emails tab in the Auto Order Editor shows the same delivery detail for a subscription rather than a single order, which is the better view when you are tracing a rebill that failed and want the whole billing history in one place. See Edit Auto Orders.
Reading the record from your own systems
GET /order/orders/{order_id}/emails returns the same records as JSON, one object per email, with delivered, opened, clicked, bounce_type, bounce_sub_type, bounce_diagnostic_code, skipped, and skip_reason:
curl https://secure.ultracart.com/rest/v2/order/orders/DEMO-1234/emails \
-H "x-ultracart-simple-key: YOUR_API_KEY" # <- your merchant API key
The auto order equivalent is GET /auto_order/auto_orders/{auto_order_oid}/emails. Both need the read scope for the record you are asking about, order_read or auto_order_read. Full parameters and response schemas are in the API Reference.
Both endpoints answer for one record at a time, so they suit a support tool or a per-order lookup. They are the wrong tool for a rate across thousands of orders.
Delivery and open rates across the whole account
Email Delivery answers what happened to one order's email. To answer what your open rate on billing update emails was this quarter, use the data warehouse, where the same records arrive as the emails array on each order and can be aggregated with SQL.
Email Delivery and Engagement Queries has ready-to-run queries for delivery and open rates by email, bounce causes, and payment recovery by engagement.
Related Documentation
-
Review Order covers the rest of the order detail screen and the other diagnostics.
-
Edit Auto Orders has the subscription-level Emails tab.
-
Transactional Emails is where the templates behind these messages are edited.
-
Email Sending Domains is the prerequisite for any of this being recorded.
-
Accounts Receivable Retry configures the payment retry schedule that the billing update emails accompany.
-
Email Delivery and Engagement Queries aggregates these records across the whole account.