Iterable Auto Order (Subscription) Events

UltraCart auto orders are subscriptions — recurring orders that rebill on a schedule. The Iterable integration sends both the recurring purchases and a set of lifecycle events so you can build subscriber journeys: welcome series, renewal reminders, failed-payment dunning, and win-back.

The subscription and rebill flags

Every purchase and shipment event (see the Iterable Events Reference) carries two flags you can branch on:

Flag	Meaning
subscription	true when the order is part of a subscription (auto order)
rebill	true when the order is a renewal, rather than the original signup order

A first-time subscription order has subscription = true and rebill = false; a renewal has both true. A one-time order that has nothing to do with a subscription has neither. Use these in a Journey to send a welcome series on the first order and a different message on renewals.

Only Flag Subscription For Physical Items

The problem this solves. If your subscription product is digital — a membership, a club, or any item with no shipping weight — and a shopper buys it in the same cart as one-time physical products, the whole order is flagged subscription = true. Those one-time buyers can then wrongly enter your subscriber journeys, because from Iterable's point of view the order looks like a subscription.

What the setting does. Turn on Only Flag Subscription For Physical Items on the Iterable configuration screen, and UltraCart sets the subscription flag only when at least one of the subscribed items is a physical item (one that has shipping weight). A subscription made up entirely of weightless / digital items no longer flips the flag, so an order that merely bundles a digital subscription with one-time physical products is not treated as a subscription.

Example. A shopper buys a physical supplement (a one-time purchase) and adds a digital membership with a free trial (a subscription). With the setting off, the order is flagged subscription = true and the shopper could enter your subscriber flow. With the setting on, the only subscribed item is the weightless membership, so the flag is not set and the shopper stays in your standard one-time-buyer messaging.

Defaults and safety:

• Off by default. Existing behavior is unchanged unless you turn it on, so no merchant is affected without opting in.
• Conservative. Genuine physical subscriptions are never dropped. If UltraCart cannot positively determine that a subscription is entirely digital, it leaves the subscription flag on. The flag is only suppressed when every subscribed item is confirmed weightless.
• This setting affects only the subscription flag on the purchase and shipment events. It does not change the auto order lifecycle events below, which fire based on the subscription itself.

Auto order lifecycle events

These events are all controlled by the single Send Auto Order Lifecycle Events checkbox. Their Iterable event names all begin with uc_autoorder_.

Event	Fires when	Build with it
uc_autoorder_created	A subscription is created (signup). Fires alongside the first purchase.	Welcome / onboarding series
uc_autoorder_renewed	A rebill is paid. Fires right after the renewal purchase. A declined rebill never sends it.	Renewal receipt, loyalty milestones
uc_autoorder_paused	The whole subscription is paused	Pause confirmation, win-back timing
uc_autoorder_resumed	A paused subscription resumes	Welcome-back message
uc_autoorder_payment_failed	A rebill payment is declined, including a declined rebill sent to Accounts Receivable	Dunning journeys (update-payment prompts)
uc_autoorder_cancelled	The whole subscription is cancelled	Win-back, exit survey
uc_autoorder_item_paused	A single item in the subscription is paused	Item-level messaging
uc_autoorder_item_unpaused	A single item resumes	Item-level messaging
uc_autoorder_item_cancelled	A single item is scheduled to cancel	Item retention offer
uc_autoorder_item_reactivated	A scheduled item cancellation is undone	Confirm the item is back

What the key events carry

• Created / Renewed carry the subscription's schedule type, the next renewal date, the next renewal amount, and the items on the next scheduled shipment.
• Payment Failed carries the decline reason, the next retry date, a link the customer can use to update their payment method, and the card brand and last four digits: everything a dunning email needs.
• Paused / Resumed / Cancelled carry who made the change, the reason, and the next renewal amount or date where applicable.

Renewals fire twice, on purpose. A successful rebill sends both a purchase event (so revenue and purchase history stay accurate) and a uc_autoorder_renewed lifecycle event. The purchase is sent first so revenue lands before your Journeys react to the renewal.

Declined renewals sent to Accounts Receivable

If Send Failures to Accounts Receivable is on in your Auto Order Processing settings, a declined rebill is not retried on the auto order's schedule. UltraCart places it as an order in Accounts Receivable instead, so you can follow up with the customer.

For these renewals:

• uc_autoorder_payment_failed fires when the rebill is declined, so your dunning journey still starts. The event also carries sentToAccountsReceivable set to true and the orderId of the order waiting in Accounts Receivable, so you can branch on it.
• There is no next retry date, because Accounts Receivable follows up on its own schedule.
• uc_autoorder_renewed fires only if that order is paid later, together with its purchase event. If it is rejected, no renewal event is sent.

A decline that is capture compatible (an address verification mismatch you can still capture by hand) does not send uc_autoorder_payment_failed, because you may still approve the payment.

Profile fields on these events

Lifecycle events carry the subscription details, but Iterable cannot update a contact's profile from a custom event. If a customer's first contact with your Iterable project is one of these events, for example a subscriber who signed up before you connected Iterable, their profile holds only an email address.

Turn on Send Profile With Events on the Iterable configuration screen to fix that. Before each lifecycle event, UltraCart then updates the contact's name, address and phone number from the subscription's order. Blank values are never sent, so this fills in missing details without clearing any you already have. It is off by default because it adds one Iterable API call per event. See Iterable Events Reference for the other events it covers.

Journey ideas

• Welcome series — trigger on uc_autoorder_created; introduce the subscription, set expectations for the next shipment.
• Renewal reminder / receipt — trigger on uc_autoorder_renewed; thank the subscriber and surface the next renewal date.
• Dunning — trigger on uc_autoorder_payment_failed; send the update-payment link, then follow up before the final retry.
• Win-back — trigger on uc_autoorder_cancelled; offer an incentive to restart.