Переотправка нотификаций

Lamoda B2B Platform Partner API позволяет запросить повторную отправку нотификаций по заказам. Это полезно, если ваш сервис был недоступен или вы потеряли часть данных.

Когда использовать

Переотправка нужна в следующих случаях:

• Ваш сервис был недоступен и пропустил нотификации
• Произошла ошибка обработки и данные не сохранились
• Нужно синхронизировать состояние заказов после сбоя
• Вы мигрируете на новую систему и хотите получить актуальные статусы

Метод API: переотправка

GET /api/v1/notifications/resend — запрос на переотправку нотификаций по переданным номерам заказов.

Формат запроса

В теле запроса передаётся JSON-объект с массивом номеров заказов (trackingId) в поле trackingIdCollection.

Формат trackingId должен соответствовать номеру заказа (строка из заглавных латинских букв, цифр и дефисов, длиной от 3 до 20 символов).

GET /api/v1/notifications/resend
Content-Type: application/json
Authorization: Bearer {access_token}

{
    "trackingIdCollection": [
        "55566123",
        "55566124",
        "55566125"
    ]
}

Формат ответа

В успешном ответе возвращается массив объектов с номерами заказов, принятых к обработке. Для каждого заказа возвращается столько записей, сколько нотификаций будет переотправлено.

HTTP/1.1 200 OK
Content-Type: application/json

[
    {
        "trackingId": "55566123",
        "inProgressUntil": "2025-12-02 15:52:01"
    },
    {
        "trackingId": "55566123",
        "inProgressUntil": "2025-12-02 15:52:01"
    },
    {
        "trackingId": "55566124",
        "inProgressUntil": "2025-12-02 15:52:01"
    }
]

В примере выше для заказа 55566123 будет переотправлено 2 нотификации, для 55566124 — 1 нотификация.

Если запрошенный заказ не найден в системе нотификаций, он просто не будет включён в ответ (без ошибки).

Как работает переотправка

При переотправке система находит все ранее созданные нотификации для указанных заказов, сбрасывает их статус и помещает в очередь на повторную отправку. Нотификации отправляются на тот же URL, который настроен для получения нотификаций.

Порядок переотправки

Нотификации переотправляются в хронологическом порядке их создания (по created_at ASC):

1. Сначала statusChanged при создании заказа
2. Затем statusChanged при подтверждении
3. Затем statusChanged при отгрузке
4. И так далее, включая itemStatusChanged и fulfilmentShipmentStatusChanged

Убедитесь, что ваш сервис готов принять повторные нотификации и корректно обработает дубликаты.

Ограничения

Номер заказа может быть передан в запросе на переотправку нотификаций не чаще, чем раз в несколько минут. При повторной отправке раньше разрешённого времени вернётся ошибка 429 Too Many Requests.

Ошибки

400 Bad Request — ошибка валидации (неверный формат trackingId):

{
    "code": 400,
    "message": [
        {
            "trackingId": "123",
            "message": "This value is not valid."
        }
    ]
}

401 Unauthorized — ошибка авторизации:

{
    "code": 401,
    "description": "...",
    "message": "OAuth2 authentication required",
    "errors": []
}

429 Too Many Requests — rate limit (повторный запрос для заказа, который ещё в обработке):

{
    "code": 429,
    "description": "Rate limit has been reached",
    "message": "Operation is in progress for tracking id '55566123'"
}

500 Internal Server Error — внутренняя ошибка сервера:

{
    "code": 500,
    "description": "...",
    "message": "Internal server error",
    "errors": []
}

Просмотр истории нотификаций

Перед переотправкой можно проверить, какие нотификации существуют для конкретного заказа:

GET /api/v1/notifications — получение списка нотификаций по заказу.

GET /api/v1/notifications?order_id=55566123&limit=10&page=1
Authorization: Bearer {access_token}

Этот метод можно использовать для диагностики: проверить, были ли нотификации созданы, и в каком они статусе.

Рекомендации

• Идемпотентность — ваш обработчик должен корректно обрабатывать повторные нотификации с одинаковым sequenceNumber
• Не запрашивайте все заказы — указывайте только те, по которым действительно нужна синхронизация
• Учитывайте нагрузку — при запросе 100 заказов с большой историей изменений вы получите сотни нотификаций за короткое время
• Проверяйте пустой ответ — если заказ не найден в системе нотификаций, он просто не попадёт в ответ; пустой массив [] означает, что ни один из запрошенных заказов не найден
• Используйте GET для диагностики — перед переотправкой проверьте историю нотификаций через GET /api/v1/notifications?order_id=...

См. также

• Настройка вебхуков
• Типы нотификаций
• Примеры нотификаций
• Статусы заказов