How should Sendium handle delivery receipt feedback?

[DimitriosPetrakis]

In SMS infrastructure, sending a message is only the first part of the operation.

The harder question often comes after submission:

What happened next?

A message may be accepted by the gateway or provider, but the final delivery outcome may arrive later through a delivery receipt. That feedback may indicate delivery, failure, expiry, delay, or another provider-specific state.

For Sendium, we would like to better understand how operators, developers and platform teams expect delivery receipt feedback to behave in real-world SMS gateway environments.

Some questions to start the discussion:

• How do you currently use DLRs in production?
• What delivery states are most important to expose clearly?
• Should provider-specific DLR details be preserved, normalized, or both?
• How should failed, expired, delayed or unknown states be represented?
• How important is DLR forwarding to external systems?
• What would make DLR handling easier to debug or operate?

The goal is to make delivery feedback useful, understandable and practical for real SMS operations — not just to receive a status and store it somewhere.

We would be happy to hear how others approach this.