---
title: "Performance, terms of service and delivery failures"
slug: "performance-terms-of-service-and-delivery-failures"
updated: 2024-09-23T16:01:08Z
published: 2024-09-23T16:01:08Z
canonical: "support.lusid.com/performance-terms-of-service-and-delivery-failures"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://support.lusid.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 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](/v1/docs/understanding-all-the-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](/v1/docs/using-mustache-templates-to-enrich-notifications) 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](https://www.lusid.com/docs/api/notification/endpoints/deliveries/ListDeliveries) API to retrieve unsuccessful attempts at delivering notifications, for example:

```json
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](https://www.finbourne.com/contact) if you think you are experiencing this issue).

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

```json
 {
  "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.](/v1/docs/filtering-information-retrieved-from-lusid)
- `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.