Production Readiness Checklist for A2P SMS over HTTP and SMPP

What production-ready means

An operational HTTP or SMPP connection only confirms that some level of communication with the remote system exists. It does not prove that the provider accepted every message, that a delivery report was received, or that an SMS reached the device.

Separate connection acceptance, acceptance of each submission, and evidence of delivery. Define what result you expect to observe at each stage and which source provides it. A DLR is a report that has been received; by itself, it is not an independent verification on the phone.

Before opening traffic, agree on the scope: destinations, senders, message types, expected volumes, schedules, responsible parties, and applicable authorization and compliance requirements. Technical acceptance does not replace review of permissions, consent, or local rules.

• Document what counts as a successful connectivity test and what counts as a delivery test.
• Agree on integration parameters and expected results with the other party; do not assume undocumented values.
• Exclude any delivery guarantee from the acceptance criteria unless it is supported by evidence and agreed conditions.

Prepare the environment and separate testing from live traffic

Keep test and production environments, credentials, destinations, and senders separate wherever the architecture and provider allow. If complete technical separation is unavailable, document safeguards to prevent a test from reaching real recipients.

Store credentials using restricted-access mechanisms and avoid including them in logs, tickets, or shared examples. Grant permissions only to those who need them, and define what to do if a credential is exposed.

Use only authorized destinations and content for testing. Before sending, check the traffic scope and approval, especially for marketing messages, OTPs, or transactional communications.

• Inventory the credentials, hosts, ports, senders, destinations, and owners for each environment.
• Ensure test messages are identified and not mixed with production traffic reports.
• Establish who can enable traffic and who can stop it.

Validate the HTTP integration

Verify authentication and transport against the documentation agreed with the provider. Confirm that the application distinguishes an HTTP response from the operational outcome of a message: receiving a response is not enough to conclude that delivery occurred.

Set connection and response timeouts in line with the implementation and technical contract. If a timeout expires, the outcome may be uncertain: the remote system may have processed the request even though the application did not receive the response. Do not retry automatically without a policy that accounts for duplicates and idempotency.

Classify errors according to the response documented by the other party. Distinguish failures that can be fixed by correcting the request or configuration from those that may be transient. The available evidence does not define codes, retries, or universal semantics for SMS APIs; agree on these behaviors before sending production traffic.

If retries are planned, define limits, delays, and stopping conditions. Ensure that a retry does not multiply submissions when a response is ambiguous, and that any deduplication mechanism is documented and tested.

• Test valid and invalid credentials without exposing secrets in logs.
• Verify success and error responses using examples documented by the provider.
• Simulate timeouts and confirm how requests with uncertain outcomes are identified.
• Test the retry policy and duplicate handling before enabling automatic resubmissions.

Validate the SMPP session

SMPP v3.4 is a relevant specification for this type of connection, but operational values must be agreed with the other party. Before opening traffic, confirm the connection parameters and session configuration that actually apply to your link.

Check that the bind type and session parameters match the agreed use. Define how idle sessions are detected, how session status is monitored, and how disconnects or controlled shutdowns are handled. Do not assume intervals, window values, or responses: they must come from the applicable specification and technical agreement.

Ensure the application can distinguish a connected session from one that is ready to transmit within the agreed limits. Test recovery after connection loss without assuming that pending messages were processed or discarded.

• Validate connection parameters and credentials with the other party.
• Agree on bind behavior, activity checks, and session closure.
• Confirm how pending submissions are reconciled after a disconnect.
• Log protocol errors and correlate them with the affected session.

Agree on limits, queues, and backpressure

Do not infer a connection’s capacity from its acceptance of test messages. Before enabling traffic, obtain applicable limits—such as the permitted sending rate or concurrency—from the other party and the contracted configuration. There is no universal TPS recommendation without that information.

Define how queues behave when the application produces messages faster than the integration can process them. Set when the sender slows down, when new work is no longer accepted, and how to prevent a burst from turning a temporary problem into a backlog that is difficult to recover from.

Test gradually and within the agreed limits. If a load test has not been authorized, do not run one; first request an explicit plan and conditions.

• Record the agreed limits and where they apply: the application, connection, or provider.
• Define thresholds for slowing or stopping message production.
• Check queue behavior and recovery after an interruption.
• Avoid unauthorized load tests or tests based on assumed limits.

Traceability, statuses, and DLRs

Each message should be traceable from the original request through the responses and subsequent updates received. Define which identifier each system retains and how the internal identifier, the reference returned by the platform, and subsequent events are linked.

Record timestamps and statuses with enough context to investigate incidents. Limit personal data and stored content to what is necessary, protect logs, and define who may access them and for how long, in line with applicable obligations.

If you receive callbacks or DLRs, test how they are authenticated, correlated, and processed, including repeated or late events if the interface supports them. Present a received DLR as the status reported by the relevant source—not as independent proof that a person saw the message or that it reached a particular device.

• Correlate the request, initial response, and subsequent events using documented identifiers.
• Record the time, status, destination, and technical context needed for diagnosis.
• Test callbacks and DLRs against documented behavior without attributing more certainty to them than they provide.
• Define access controls and retention periods for logs.

Run controlled tests and assess the evidence

First run transport and configuration tests using approved cases. Then, if authorized and an appropriate test destination is available, assess the submission flow and available reports. Keep connectivity results separate from delivery results.

Classify each observation: request submitted, acceptance reported by the interface, DLR received, and, where possible, receipt independently verified at a controlled destination. These categories are not interchangeable. A test involving a small number of messages does not, by itself, establish behavior across all destinations or volumes.

Document the results, time, environment, parameters used, and limitations. If a response is missing or statuses conflict, treat the case as inconclusive until it has been investigated.

• Approve test destinations, senders, and content in advance.
• Check connectivity first, then the message status flow.
• Retain enough evidence to reproduce the diagnosis without storing secrets.
• Do not turn a limited sample into a general deliverability guarantee.

Alerts, ownership, and rollback

Before launch, assign owners for integration, operations, and contact with the other party. Define how to detect lost connectivity, rising errors, growing queues, and status discrepancies using signals available in your system.

Agree on explicit stop criteria, such as failures that prevent you from identifying the outcome of submissions, exposed credentials, or a deviation from agreed limits. Set specific thresholds based on the service data and agreements, not invented figures.

Prepare a rollback plan before enabling traffic: who can stop new submissions, how pending work will be handled, how affected teams will be notified, and what conditions must be met before resuming. Stopping new message production does not automatically resolve the status of messages already sent; those cases must be reconciled.

• Assign an on-call owner and an escalation channel.
• Define observable signals and agreed thresholds for alerts and stopping traffic.
• Test the procedure for stopping new submissions and handling pending work.
• Document resumption conditions and the post-incident review.