Loops Receipt Retries: Keep Approved Content Stable

A retry should not quietly become a different receipt. If a Node job times out and the next attempt reads a newly edited template or changed order values, the team may no longer know which message the customer received.

Prepare the approved receipt design in Migma, then have the Node and Loops owners preserve the intended business facts and reconcile uncertain sends. This guide is published by Migma. It focuses on the creative contract around retries, not on installing a delivery integration or claiming that Migma operates Loops automatically.

Decide what counts as the same message

Use a fictional order for two notebooks. The intended receipt names the items, the approved totals, and the order reference. Those facts describe a specific business event. A later refund or address correction is another change to consider explicitly, rather than something to slip into a retry without review.

Write a small record of what the first send was meant to communicate. Include the event reference, intended recipient, reviewed template version, required values, and the owner of each fact. Keep unnecessary payment or personal details out of creative review notes.

The useful question is not simply “Did the code run again?” It is “Was the next attempt intended to communicate the same approved event to the same person?” If the answer changes, stop treating the action as an ordinary retry and ask the responsible owner how a correction should work.

Separate design approval from send identity

Migma's documented workflow prepares copy, design, images, and an email-safe build for review. That makes it useful for agreeing on the receipt's layout and wording. It does not establish which provider request was accepted or whether a customer already received it.

Keep the approved creative alongside the event-to-template mapping. If the destination uses a shared Loops template, record how the implementation controls changes while a sending job is pending. Do not assume that saving a local screenshot freezes the template used by an application.

Review both the factual content and the action. An order-status link should refer to the same order as the receipt. A generic “View your order” button does not make an incorrect destination harmless. Ask the implementation owner to inspect populated examples, not just empty variable names.

Use the provider's current retry contract

Loops' Node resource discusses transactional sending and retry handling. For the exact provider behavior, use the transactional endpoint documentation, checked for this guide on October 17, 2026.

That endpoint documents an optional Idempotency-Key to avoid duplicate requests and a 409 response when a key has already been used within its stated window. The sending owner must apply the current contract correctly. A new key chosen simply to get past a conflict can undermine the duplicate protection the team was trying to preserve.

This article supplies no retry code or universal error-handling recipe. The responsible engineer should determine how temporary failures, permanent failures, and uncertain responses are recorded and reconciled. Creative review should provide the stable message facts that process needs, rather than inventing a separate delivery state.

Review three situations before release

For an unchanged retry, confirm that the intended event, recipient, values, and reviewed content remain the same. Ask how the job refers to that approved version and how the owner can inspect the provider outcome later.

For a changed receipt, identify what changed and why. A corrected quantity, a refund, or a new recipient may require a separately approved communication. Avoid overwriting the first message's meaning in an attempt to make the latest screenshot look right.

For an uncertain response, preserve the uncertainty until the sender reconciles it. A timeout does not prove the provider accepted nothing. Do not let a marketer's desire to “make sure it arrived” become an unreviewed second send from another path.

Check the final rendered receipt

Use Migma's HTML handoff as the reviewed creative reference. The Loops owner must confirm the supported way to implement that design and fill its variables. This guide does not imply a native Migma-to-Loops connection.

Inspect a receipt with several items, a long product name, a missing optional value, and a corrected order. Required transaction facts should not be replaced with plausible guesses. If a fact is unavailable, the business owner must determine whether the message can still be accurate.

Run Email Preflight for relevant writing, links, layout, and inbox previews. Then use the sending owner's controlled test process for the final destination template and retry cases. A design check cannot establish provider acceptance or guarantee inbox placement.

Keep corrections visible to the team

Save the approved content, event mapping, test cases, and reconciliation owner together. When the shared template changes, review pending-job implications with the engineer before assuming only future messages will be affected.

The practical result is a receipt the team can explain: what it says, which event it describes, and which sending evidence supports its status. Start the creative in Migma, and keep retry decisions attached to the actual provider and application records.

Frequently Asked Questions