You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Most of systems have their own internal tables to track the sent messages and updating the status. To identify the response for every message we can't just rely on to/from fields because multiple messages can be sent to the same phone number.
Another solution is to let consumer can optionally add RefId field, which will be delivered back in webhook response. Consumer then can use this RefId to update internal tables.
Also, in case of webhook delivery failed for any reason, consumer can query the message status using RefId at any time.
When you send a message, the system generates an ID for that message. You store this ID in your database.
When you get a delivery report, you check this delivery report gainst the message ID.
Message ID will be received in response to sending the message, if response not received for any reason, then no consumer will consider message is not sent. Later once webhook provide the status, status can't be updated.
So, in worst case, consumer will consider the message is not sent and re-send again. Eventually, it will lead to message duplicate.
By providing Ref Id ahead (during submission), you have full control.
My suggestion to make it optional parameter, so api consumer can use any Id system (message ID or Ref ID).
Will this feature mean I'll have to build the "deduplication" logic on my end, So if you send 2 SMS messages with the same reference ID, I should only send out 1 of them?
The logic should not change, what I suggest is to add provided Reference ID to message response. Then consumer have the option to use Message ID or Reference ID in his internal logic.
As I mentioned, it is optional ID, so it should not be involved in any logic. It is something API consumer may use.
Activity
AchoArnold commentedon Jul 14, 2023
Hello @ay1man4
Can you use the message ID to achieve this?
When you send a message, the system generates an ID for that message. You store this ID in your database.
When you get a delivery report, you check this delivery report gainst the message ID.
You can currently fetch messages by ID
ay1man4 commentedon Jul 16, 2023
Message ID will be received in response to sending the message, if response not received for any reason, then no consumer will consider message is not sent. Later once webhook provide the status, status can't be updated.
So, in worst case, consumer will consider the message is not sent and re-send again. Eventually, it will lead to message duplicate.
By providing Ref Id ahead (during submission), you have full control.
My suggestion to make it optional parameter, so api consumer can use any Id system (message ID or Ref ID).
Thansk.
AchoArnold commentedon Jul 17, 2023
Hello @ay1man4
Will this feature mean I'll have to build the "deduplication" logic on my end, So if you send 2 SMS messages with the same reference ID, I should only send out 1 of them?
ay1man4 commentedon Jul 17, 2023
Hi Arnold,
The logic should not change, what I suggest is to add provided Reference ID to message response. Then consumer have the option to use Message ID or Reference ID in his internal logic.
As I mentioned, it is optional ID, so it should not be involved in any logic. It is something API consumer may use.
AchoArnold commentedon Jul 17, 2023
@ay1man4
I got you now, I'll add the optional reference ID.
Thanks for explaining.