Duplicate and Out-of-Order Events in A2P SMS: How to Reconcile Them Without Losing Evidence

Why Events Can Be Duplicated, Delayed, or Arrive Out of Order

In an A2P integration, a submission can produce observations at more than one stage: an API request, an acceptance or rejection response, an SMPP interaction and, if available, a delivery report (DLR). These signals do not necessarily arrive together or in the order in which events occurred. Notification retries or repeated events are also possible.

The precise semantics depend on the interface and provider. There is no universal precedence rule that allows you to conclude, across all systems, that an API event takes precedence over an SMPP event, or that every DLR means the same thing. Document what each event represents in your integration before using it to update a status.

• Keep separate the time the system says an event occurred and the time your platform received it.
• Treat repeated messages as an operational possibility, not proof that the underlying event happened multiple times.
• Do not assume that a missing event means failure, delivery, or cancellation.

Separate the Original Event Log from the Calculated Status View

Keep two concepts distinct. The event log preserves what was received; the operational projection summarizes what the platform can assert at that point in time. If a reconciliation rule changes, the projection can be recalculated from the log without deleting or rewriting the evidence that produced the result.

For each event, preserve the received content, source or interface, correlation identifier, declared and observed timestamps, and validation results when available. Avoid replacing an earlier event with a later one simply because the latter seems more conclusive.

Retention, tamper protection, and audit requirements should reflect your organization’s obligations and applicable contracts. This does not establish a universal guarantee of immutable storage.

• Save the original observation and record any normalization separately.
• Version the rules used to calculate the projection.
• Make it possible to reconstruct which events and rules produced the displayed status.

Define Identity and Deduplication Without Assuming a Global Key

Do not assume there is a unique identifier shared across APIs, SMPP, aggregators, and operators. An identifier may be valid only within an account, connection, provider, or time period. Define the scope of each identifier according to the documentation for the specific interface.

If there is no reliable key, do not merge events just because the recipient, text, and approximate time match: two legitimate messages can share those attributes. In that case, preserve both and mark them as possible duplicates or as uncertain correlations rather than discarding evidence.

Normalizing a number can make searches easier, but does not by itself prove that two records refer to the same submission. E.164 is a numbering recommendation; it does not, on its own, provide a message-correlation rule.

• Start with the identifier documented by the interface and its scope: account, connection, or provider.
• Record the deduplication rules and the reason for each match.
• If correlation is ambiguous, preserve the event and avoid automatically merging messages.

Order Events Cautiously: Declared Time, Observed Time, and Sequence

Preserve separately the timestamp included by the event sender and the time your system observed it. A declared time may describe when the event originated; the observed time documents when it reached your platform. Neither should silently replace the other.

If the interface provides a sequence or version with documented semantics, consider using it within the scope for which it is valid. If there is no reliable ordering signal, do not treat arrival order as a definitive chronology. A stable tie-breaking rule can make a calculation repeatable, but it does not prove what happened first.

Record the time zone, precision, and possible clock issues when that information is available. If it is missing, retain that limitation in the event assessment.

• Store at least the declared time and receipt time as separate fields.
• Apply sequence information only when you know its scope and meaning.
• Mark relative ordering as uncertain when the evidence does not resolve it.

Define Explicit Transitions and Do Not Infer Delivery

Design a state machine for your system based on the meanings documented for each interface. There is no universal precedence between acceptance, error, intermediate status, and DLR that can be applied without knowing the provider and technical contract.

A submission acceptance indicates only what the interface documents about the request. A DLR must be interpreted according to its source and semantics; receiving one does not automatically amount to independent verification that the person saw the SMS or that the message reached the device in every case.

When the evidence is insufficient to decide, show a status such as “pending,” “unknown,” or “conflict,” according to your model. The label should make clear that delivery is not confirmed.

• Document which events allow each transition and what they mean in that integration.
• Define conditions for retaining an uncertain status and for escalating a contradiction.
• Do not turn a missing DLR, an acceptance, or an uninterpreted code into confirmed delivery.

Handle Contradictions and Late DLRs Without Losing the History

If a DLR arrives after the interface has reported a failure, or if two sources appear to contradict each other, preserve both events and assess their meaning according to the applicable documentation. Do not delete the earlier event or automatically choose the latest one: receipt time alone does not establish which event has greater authority.

The projection can be updated when a new observation provides relevant evidence, but record what changed, when it was recalculated, and which rule was applied. If the conflict cannot be resolved, keeping it visible is more accurate than hiding it behind a single definitive status.

• Record contradictions as an explicit condition, not as a silent overwrite.
• Define when a rule allows a conflict to be resolved and when review is required.
• Preserve late events for auditing and reprocessing.

Make Reconciliation Repeatable and Auditable

Reprocessing should produce the same result when run with the same event set, rules, and configuration version. To work toward this property, separate ingestion from projection and avoid making the result depend on unrecorded side effects.

Idempotency can be applied to notification processing when a reliable identity and defined scope are available. Without them, aggressive deduplication can discard valid evidence. It is preferable to record the criterion used, preserve the received observation, and flag uncertain matches.

Monitor unusual patterns, such as increases in repeated events, unusual delays between event types, or recurring contradictions. Alerts should describe what was observed; do not attribute a cause without evidence.

• Version projection rules and record the version applied.
• Allow statuses to be recalculated from the preserved history.
• Measure duplicates, delays, and conflicts by interface and scope without presenting them as quality guarantees.

Example: Acceptance, Temporary Failure, and a Late DLR

Suppose the API responds with an acceptance of the request. Later, a signal arrives that your integration interprets as a temporary failure, and then a DLR appears. The exact names and meanings must come from that provider’s documentation; this example does not establish a normative sequence.

First, preserve all three events with their declared and receipt times, identifiers, and known scope. Check whether they can be correlated reliably. Then apply the documented rules: acceptance does not prove delivery, the temporary failure should not be erased because another event arrived later, and the DLR can support only the conclusion allowed by its semantics.

If the documentation establishes that this DLR represents a delivery result for the correlated message, the projection can reflect that result with its scope clearly stated. If its semantics, identity, or relationship to the submission are unconfirmed, keep the status uncertain or in conflict. Under no circumstances does this example allow you to claim that the user saw the SMS or that receipt on the mobile device was independently verified.

• Conclude that an acceptance, a failure signal, and a DLR were received; their correlation and meaning must be verified.
• Do not conclude without documentation that acceptance confirms delivery or that the DLR proves actual receipt by the user.
• Leave unresolved any identity, ordering, or semantic conflict that the available evidence cannot settle.