A2P SMS Messages in an Uncertain State: How to Reconcile Evidence Without Resending Prematurely

What it means for a message to be in an uncertain state

“Uncertain” can be used as an internal category to indicate that the available evidence does not establish the outcome under the criteria defined for an integration. The information provided here does not support a universal technical definition of this state.

Distinguish known facts, such as a sending attempt or a response from an interface, from conclusions that have not been demonstrated. Do not assume that acceptance means delivery, or that a lack of response proves failure.

The meaning of each status and the evidence supporting it depend on the applicable interface and documentation. Without relevant documentation, it is not possible to establish general rules for API responses, SMPP sessions, or delivery reports (DLRs).

• Record observed facts separately from the internal interpretation assigned to them.
• Do not turn a lack of response into a claim about what happened in the remote system.
• Define any operational category based on the available documentation and the specific agreement.

Gather evidence and preserve the available information

A review can begin by gathering records already available in the application, interface, and messaging platform. Note which system provided each item and when it was recorded. These are suggested internal organizational practices, not a description of how any specific technology behaves.

Do not assume that identifiers from different systems are equivalent or can automatically correlate events. Consult the documentation for the relevant integration to determine whether they can be linked.

If the team creates an internal classification or normalizes statuses, it can also preserve the value received and document the internal rule applied. The evidence provided does not determine how correlation or event handling should be implemented.

• As a suggested internal control, record available references, timestamps, and the system of origin.
• Document correlation limitations rather than attributing evidence to a send without a basis.
• Where your team’s process allows, preserve the distinction between the data received and the internal interpretation.

Define interface-dependent internal criteria

A team can establish internal criteria for classifying cases and deciding when to review them. Without sufficient technical documentation, present those criteria as the team’s own controls, not as a universal state machine or behavior expected of all providers.

Document what available information leads to each internal decision and how cases with incomplete or contradictory data are reviewed. The evidence provided does not specify the behavior of duplicate or delayed events, or establish general technical transitions.

If two records appear incompatible, preserve the discrepancy as such and consult the applicable documentation. Do not automatically choose one status because it is newer or more favorable.

• Identify categories and rules as internal when they are not defined by the interface documentation.
• Adapt any criteria to the information actually available for the integration.
• Record discrepancies and avoid resolving them through assumptions.

Apply prudent closure rules

Closing a case is an operational decision that should be based on the criteria defined for the integration. The available evidence establishes neither a common time limit nor a universal list of final statuses.

These sources cannot directly confirm what a DLR with a “delivered” status means on each platform. Therefore, do not present it as universal proof of receipt on the handset or attribute the same semantics to every platform.

When closing a case, separate the status reported by the system from any additional conclusion about receipt. State that receipt is verified only when the integration provides suitable evidence and its limitations are known.

• Define closure criteria according to the applicable documentation and agreements.
• Describe a DLR as a reported status; do not generalize about what it proves.
• Record any uncertainty that remains when closing the case.

Choose whether to wait, query, close, or escalate

The action depends on the tools documented for the integration and the criteria agreed by the team. The information provided does not confirm that a query function exists for every provider or interface.

As a suggested internal control, the team can define when to keep a case open, when to use a documented query function, and when to escalate a discrepancy. If the outcome cannot be determined, the team can mark it as indeterminate under its own process.

When sharing a case with a provider, use the information needed to describe the discrepancy and follow applicable data protection rules. These recommendations are organizational guidelines, not confirmed technical capabilities.

• Wait: an internal process option if the case is still within the agreed criteria.
• Query: only if the interface documentation describes an applicable query function.
• Escalate: an internal option for a discrepancy or insufficient information requiring review.
• Close as indeterminate: an internal decision when the agreed process does not support concluding another outcome.

Avoid automatic resends, especially in OTP flows

The available evidence does not establish which deduplication, query, or retry mechanisms different platforms offer. Therefore, a timeout, missing DLR, or pending status should not be treated here as sufficient proof of failure or as a universal technical signal to resend.

As a suggested internal control, separate investigating the original send from deciding to initiate another one. Before a new attempt, follow the retry policy documented for the application and integration; do not assume the system will recognize a repeated request as the same operation.

In OTP flows, follow applicable business, security, privacy, and consent rules. Communicate the known status clearly, without presenting a retry as a guarantee of delivery.

• Do not attribute deduplication or idempotency to an interface without documentation confirming it.
• Apply the retry controls defined for the application and integration.
• In OTP communications, avoid presenting a new attempt as a guarantee of the outcome.

Practical decision framework

This framework is an internal aid, not an API specification or a universal description of the statuses providers offer. Adapt it to the applicable documentation and agreements.

Before using it, confirm what information the interface provides and what conclusions it supports. If the source or relationship between records cannot be identified, note that limitation.

• Acceptance response with no subsequent information: interpret the response only as provided by the applicable documentation; any wait or query is an internal process decision.
• No response to the request: record the observed fact; do not automatically conclude whether it was accepted or what happened afterward.
• DLR received: preserve the reported status and consult its definition; do not turn it into a universal claim of receipt on the handset.
• DLR with no reliable correlation: do not attribute it to a send without a documented basis.
• Incompatible information: preserve the available data and follow the internal review or escalation process.
• Insufficient evidence: classify the case according to the internal process, without claiming an outcome that has not been demonstrated.

Review uncertainty and decisions

An indicator of uncertain cases is interpretable only if the team defines which cases it includes, the period observed, and how subsequent changes are recorded. The available evidence provides no performance benchmarks or figures to use.

An internal process can review open cases, discrepancies, correlation limitations, and resend decisions. Keep categories based on reported statuses separate from claims of verified receipt.

A review can help identify gaps in documentation or process. Do not attribute conclusions to an indicator that the data cannot support.

• Define the period and criteria used to identify uncertain cases.
• Record discrepancies and limitations in the available information.
• Review resend decisions against the applicable internal policy.
• Distinguish reported statuses from any verified receipt.