Get full info about outbound sms via returned data from Webhook (message-store event subscription) and RC API

I am trying to retreive the full sms info from ip by filtering it with timestamp, but there is an incoherence between timestamp from webhook and timpestamps from API, so when I
pass the timestamp or last modify from Webhook data, no record is returned by
API:

webhook:

(     [uuid] => 2551637673034818887-6529932958060832289     [event] => /restapi/v1.0/account/671930005/extension/671930005/message-store     [timestamp] => 2017-02-13T12:37:12.319Z     [subscriptionId] => b56a0ae7-96e5-4b40-9e4e-c78997f0d3f3     [body] => Array         (             [extensionId] => 671930005             [lastUpdated] => 2017-02-13T12:36:59.541+0000             [changes] => Array                 (                     [0] => Array                         (                             [type] => SMS                             [newCount] => 0                             [updatedCount] => 1                         )                  )          )      [user_info] => Array         (             [user_id] => 12345             [process_id] => 12345             [company_id] => 998         )  )

API

"records": [
    {
      "uri": "https://platform.devtest.ringcentral.com/restapi/v1.0/account/671930005/extension/671930005/message-...;,
      "id": 2682475004,
      "to": [
        {
          "phoneNumber": "+13234845184"
        }
      ],
      "from": {       
"phoneNumber": "+16264932460"
      },
      "type": "SMS",
      "creationTime": "2017-02-13T12:36:57.000Z",
      "readStatus": "Read",
      "priority": "Normal",
      "attachments": [
        {
          "id": 2682475004,
          "uri": "https://platform.devtest.ringcentral.com/restapi/v1.0/account/671930005/extension/671930005/message-...;,
          "type": "Text",
          "contentType": "text/plain"
        }
      ],
      "direction": "Outbound",
      "availability": "Alive",
      "subject": "Test SMS using a RingCentral Developer account - test",
      "messageStatus": "Delivered",
      "smsSendingAttemptsCount": 1,
      "conversationId": 7544107414282913435,
      "conversation": {
        "id": "7544107414282913435",
        "uri": "https://platform.devtest.ringcentral.com/restapi/v1.0/conversation/7544107414282913435";
      },     
"lastModifiedTime": "2017-02-13T12:36:59.541Z"
    },

UPDATE: Have you tried using the Instant SMS Notification Event Type
By subscribing to this type of event notification, your event notifications will contain data hydrated with the SMS itself: 

{
    "event": "/restapi/v1.0/account/~/extension/823476228762/message-store/instant?type=SMS",
    "subscriptionId": "dc853541-66ac-45d8-a289-1a239fd72888",
    "timestamp": "2013-06-14T12:00:00.000Z",
    "body": {
           "id" : "606090030016",
           "to" : [ {
              "phoneNumber" : "+16508974563",
              "location" : "Moss Beach, CA",
           } ],
           "from" : {
              "phoneNumber" : "+14157809227",
              "name" : "Something New"
           },
           "type" : "SMS",
           "creationTime" : "2016-02-22T17:01:00.000Z",
           "lastModifiedTime" : "2016-02-22T17:01:00.000Z",
           "readStatus" : "Unread", 
           "priority" : "Normal",
           "attachments" : [ {
             "id" : "606090030016",
             "type" : "Text",
             "contentType" : "text/plain"
           } ],
           "direction" : "Inbound",
           "availability" : "Alive",
           "subject" : "Hi there",
           "messageStatus" : "Received",
           "conversationId" : "7876416245344257449"
        }
}

    "uuid":"ed1cf00c-0420-4bf5-a0ae-e659bb9f77e0", 

Currently, these records are created by different systems in our architecture respectively (AFAIK). I believe this is what is causing the timestamp differences (which I too have seen).

I have not been able to come up with a clean solution for this obstacle. I will contact our engineering team to determine if they have an alternative solution for this use case, or to get this issue on the product management team's radar.

If I discover an alternative solution, I will reply with it here as soon as possible.