An SMS provider can accept a request before the destination carrier has delivered the message. That is why the initial API response and the final delivery receipt represent different events.
IntelliSend stores message identifiers and campaign context so later provider events can update the correct record. Campaign and delivery-log views then expose that lifecycle to operators.
ClickSend, SMSGlobal, and TouchSMS use different payload shapes and capabilities. The backend has provider-specific parsers rather than forcing every callback through one assumed schema.
ClickSend can register a webhook and uses a webhook token to associate callbacks with the intended integration. SMSGlobal has its own delivery-receipt payload and notification URL rules. TouchSMS status can be refreshed through its message endpoint when callback behavior is not sufficient.
A useful delivery event must be matched to the correct tenant, provider connection, campaign, and message. External message identifiers, campaign identifiers, integration context, and authentication checks all help prevent an unrelated callback from changing the wrong record.
Delivery receipts can arrive later than the send response, and providers may send more than one status update. Handlers should tolerate repeated events and preserve the most meaningful known state rather than treating every callback as a new message.
For operators, the lesson is simple: review message logs in sequence. First confirm provider acceptance, then observe pending or intermediate states, and finally use the delivery receipt as the best available evidence of the outcome.
