API для страховых компаний: автоматизация выплат за задержку рейса

Параметрическое страхование задержки рейса — продукт, где выплата не требует заявления и сбора документов: как только рейс из полиса фактически задержан на N минут, деньги уходят клиенту автоматически. Единственное, что для этого нужно, — надёжный источник фактического времени вылета/прилёта и способ узнать о задержке сразу, а не при следующем ручном опросе.

Почему polling не подходит для страхового триггера

Опрос API раз в час означает, что выплата (и репутационный эффект «мгновенной страховки») задерживается на тот же час. Для параметрического продукта критична скорость реакции — вебхук от Tablo API присылает POST-запрос на ваш эндпоинт сразу при смене статуса рейса, без опроса.

Датированная подписка на конкретный рейс полиса

При оформлении полиса вы знаете дату вылета заранее — оформите вебхук на конкретную дату рейса и задайте автоотключение подписки после того, как рейс дойдёт до финального статуса:

curl -X POST -H "X-API-Key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
        "flight_name": "SU100",
        "airport_code": "SVO",
        "flight_date": "2026-10-02",
        "deactivate_after_hours": 6,
        "url": "https://your.app/webhook/policy-4471",
        "secret": "s3cr3t"
      }' \
  "https://api.tabloapi.ru/v1/webhooks"

flight_date привязывает подписку к конкретному вылету, а не к номеру рейса вообще (один и тот же номер летает каждый день). deactivate_after_hours: 6 — подписка сама деактивируется через 6 часов после того, как рейс получит статус LANDED/DEPARTED/CANCELLED: не нужно отдельным заданием чистить закрытые полисы вручную.

Считать задержку от изначально обещанного времени, а не от текущего плана

Важный нюанс: у некоторых источников поле «план» перезаписывается при каждой задержке — если считать отклонение от него, к моменту фактического вылета «план» может уже совпадать с фактом, и задержка обнулится. Для страхового триггера это неприемлемо: клиенту обещали конкретное время при покупке полиса, и именно от него нужно считать компенсацию.

Tablo API хранит date_arrival_plan_original/date_departure_plan_original — время, зафиксированное один раз при первом появлении рейса в системе и больше никогда не изменяемое, в отличие от date_arrival_plan/date_departure_plan:

{
  "data": {
    "name": "SU100",
    "status": "LANDED",
    "date_arrival_plan_original": "2026-10-02T10:30:00.000Z",
    "date_arrival_plan": "2026-10-02T11:45:00.000Z",
    "date_arrival_fact": "2026-10-02T11:52:00.000Z"
  }
}

Реальная задержка для выплаты — date_arrival_fact − date_arrival_plan_original, а не разница с обновлённым планом.

Обработка события вебхука

app.post('/webhook/policy/:policyId', express.raw({ type: 'application/json' }), async (req, res) => {
  const sig = req.headers['x-signature'];
  const expected = crypto.createHmac('sha256', WEBHOOK_SECRET).update(req.body).digest('hex');
  if (sig !== expected) return res.status(401).end();

  const event = JSON.parse(req.body);
  if (event.field === 'status' && event.new_status === 'LANDED') {
    const flight = await fetchFlight(event.flight_number, event.airport_code);
    const delayMinutes = (new Date(flight.date_arrival_fact) - new Date(flight.date_arrival_plan_original)) / 60000;

    if (delayMinutes >= 120) {
      await triggerPayout(req.params.policyId, delayMinutes);
    }
  }
  res.status(200).end();
});

Проверка подписи X-Signature обязательна — это финансовый триггер, эндпоинт не должен реагировать на поддельные запросы. Подробнее о проверке HMAC — в статье о вебхуках.

Идемпотентность важна вдвойне

При сетевых сбоях Tablo API повторяет доставку до 3 раз — для страхового эндпоинта это значит, что обработчик обязан проверять, не была ли выплата по этому полису уже произведена, прежде чем инициировать перевод повторно.

Датированные вебхуки доступны на тарифах BUSINESS и выше. Запросить доступ к API →