Performance, terms of service and delivery failures

The Notification Service aims for a median delivery lag of one second and a 99th percentile delivery lag of one minute.

The Notification Service makes two guarantees about the order in which notifications are delivered:

• Notifications for the same entity are delivered in order, so for example if you update the same instrument in LUSID multiple times then notifications for these changes are delivered in order.
• Notifications for different entities of the same type are delivered in order, so for example if you update two instruments then notifications are delivered in order.

The Notification Service does not guarantee that notifications for updates made via different applications in the FINBOURNE platform (for example Drive and LUSID) are delivered in order. Within an application, it is possible that updates to different entity types are not delivered in order, so for example if you update a portfolio and then an instrument it is possible to receive the instrument notification before the portfolio one.

If the order between entities is important then you can include {{Header.timestamp}} in notification messages to determine whether out-of-order notifications have been received and re-process where necessary.

Checking for notification delivery failures

If you suspect you are not receiving notifications as intended, you can use the ListDeliveries API to retrieve unsuccessful attempts at delivering notifications, for example:

curl -X GET "https://<your-domain>.lusid.com/notification/api/deliveries" 
  -H "accept: application/json" 
  -H "Authorization: Bearer <your-API-access-token>"

Currently, the cause of a failed delivery depends on the type of notification being sent:

• For a webhook, a failure can occur if an API request does not return a successful HTTP status code.
• For an Amazon SQS notification, a failure can occur if an exception is thrown by SQS. 
• For an email or SMS notification, a failure may occur for a number of reasons, including:
  • The rendered SMS message is too large.
  • An email domain specified no longer exists.
  • You have exceeded your quota (please contact support if you think you are experiencing this issue).

A response might look like this, with failures listed within the values object:

 {
  "values": [
    {
      "id": "76f15f61-a437-4a7c-be7f-c6bf25f8d31a",
      "eventId": "a1bbd81b-7956-467c-af86-5aaa1f4dd84e",
      "subscriptionId": {
        "scope": "PortfolioEvent",
        "code": "AnyPortfolioCreated"
      },
      "notificationId": "webhook1",
      "deliveryChannel": "Webhook",
      "messageDetails": "{\"Method\":{\"Method\":\"POST\"},\"Url\":\"https://<your-domain>.lusid.com/api/api/transactionportfolios/Test/DeliveriesTest/transactions\",\"Headers\":{\"X-LUSID-Application\":\"Notifications\",\"Authorization\":\"**********\"},\"ContentType\":\"application/json\",\"SerialisedContent\":\"[{}]\"}",
      "attempts": [
        {
          "attemptNumber": 1,
          "attemptTime": "2023-02-17T12:38:17.6333900+00:00",
          "status": {
            "result": "Failed delivery",
            "detailedMessage": "WebhookFailure: Unsuccessful response from webhook"
          }
        }
      ]
    }
  ]
}

You can specify the following parameters with the ListDeliveries API call:

• filter: Specify a string for this parameter to filter the result set. Read more about filtering.
• limit: By default, a call retrieves up to 5000 failed delivery attempts. You can specify an integer for the limit parameter to update the maximum number of delivery attempts to retrieve.
• page: If the number of failed delivery attempts exceeds the limit, the response may include a nextPage pagination token. You can call the ListDeliveries API again, passing the token into the page parameter, to list the next page of results.