On This Page
An order update arrives before an order creation event. Elsewhere, a payment event arrives before an earlier subscription event. These are illustrative teams using different products and payloads. Both are tempted to repair the issue by sorting deliveries by arrival time.
This is not a report of either team’s incident. It asks whether the two failures have a common shape even though their vendor details differ.
An ingested conversation about mathematical connections observes that apparently different problems can share a useful form. Applying that idea to software integration is an inference. It becomes useful only when the common form produces a test that each system’s documented behavior supports.
Strip away names, then put the contracts back
Describe the first case without product names: an event about a resource may arrive after a later change to the same resource. A receiver that treats arrival order as state order can overwrite newer information with older information.
Now inspect the two actual contracts. Shopify’s webhook documentation says ordering is not guaranteed, even within a topic, and gives an example where a product update can precede a product creation delivery. Stripe’s webhook documentation also says events are not guaranteed to arrive in generation order and recommends retrieving missing objects when an expected earlier event has not arrived.
Shopify and Stripe both warn that event delivery order is not guaranteed. The shared question is whether final state remains correct; each vendor's identifiers and recovery rules still need their own test.
The transferable question is: “If this event arrives before a related one, can we still derive the correct current state?” The implementation answer is not transferable by assumption. Shopify documents headers such as X-Shopify-Webhook-Id and timestamps. Stripe uses its own event IDs and object retrieval rules. An identifier that means “delivery” in one system may not mean the same thing in another.
Our Brevo connector guide addresses a separate set of field and mapping details. Those details matter to a working integration, but they should not be mistaken for universal API behavior.
The common shape is an invariant
For a customer sync, the invariant might be: after processing, the destination’s customer record reflects the authorized source’s current state. For billing, it might be: a payment-dependent action occurs only when the authoritative payment state permits it. The invariant names what must stay true even when events are late, repeated or incomplete.
Write down four things before choosing a fix:
| Question | Why it matters |
|---|---|
| Which identity names the business object? | An event ID may identify a message rather than a customer or order. |
| Which system owns the current state? | A payload may be a snapshot, a change or only a pointer. |
| What timing can the source guarantee? | Delivery order may not be state order. |
| What postcondition proves success? | Receipt of an event does not prove the destination is right. |
This table is a thinking aid, not a protocol. The source-of-truth answer depends on the workflow. A live lookup may be required in one system and inappropriate in another. Some events must be preserved as historical facts rather than collapsed into the newest snapshot.
Reuse the test, then adapt the remedy
A small contract test can send related events in the reverse order and ask whether the final destination state is still correct. Another can send the same delivery twice. These tests expose the shape of the risk. The vendor documentation then determines how to identify, verify and recover each event.
That distinction protects teams from copy-paste architecture. A deduplication key from one API can fail in another. A timestamp with coarse precision may not establish order. Fetching the current object may be necessary for a state sync but cannot reconstruct every intermediate historical event. The guide to integrating multiple business tools starts by deciding which system owns each field; without that choice, “newest” has no clear meaning.
There is a limit to pattern transfer. Similar symptoms can have different causes: a missing record might reflect an unauthorized query, a delayed webhook, an invalid mapping or a rejected write. Before declaring two cases equivalent, compare the source contract, the destination contract and the observed postcondition. If one differs, keep the shared question and change the test.
The method is useful beyond event delivery. A field accepted by an API but absent from the user-facing record raises the same general question in any connector: what does acknowledgment prove, and what evidence proves the intended state? The answer may involve a destination read, a schema lookup or a permissions check. The pattern tells the team to separate transport from meaning. It does not tell them which field or endpoint to call. That narrower lesson is less exciting than a universal integration recipe, but it travels farther because it keeps the local facts visible.
The strongest reusable lesson is not a snippet of handling code. It is a question that survives the move to another system and makes the local contract easier to examine.
Frequently Asked Questions
Can the same integration test be reused across vendors?
The question can often transfer, such as whether updates can arrive out of order. The event IDs, payload meaning, signatures and recovery steps must be taken from each vendor's contract.
What is the difference between a pattern and a copied fix?
A pattern names the failure condition and the invariant to preserve. A copied fix assumes the second system has the same identifiers, ordering and state semantics without checking.
What should be checked after applying an event?
Check the destination state required by the workflow, not merely the event receipt or HTTP response. The postcondition depends on the business object and source-of-truth rule.