Перейти к статье
API429 / Практика

FNOL через API: извлечение данных страхового заявления в JSON

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

Схема клиентского извлечения данных: FNOL через API: извлечение данных страхового заявления в JSON
Редакционная схема обработки данных в приложении клиента. Не является результатом теста модели.

Задача интеграции

FNOL — первичное уведомление об убытке. Для API-интеграции удобно начать с извлечения фактов из текста обращения: заявленная дата, место, описание и номер полиса, если он указан. Ниже — вымышленный пример через API429. Он формирует черновик карточки, но не определяет покрытие, виновность, признаки мошенничества или размер выплаты.

Подготовка исходного текста

Сохраняйте исходное обращение, его идентификатор и перечень фактически полученных вложений. В тексте клиента дата может относиться к событию, отправке сообщения или другому обстоятельству. Схема примера сохраняет названную дату без автоматического вывода о её значении; для реального процесса уточните отдельные поля и правила проверки.

Схема полей

Поле Что сохраняем Что проверяет оператор
reported_date Дату из переданного текста К какому событию она относится
place Дословное описание места Достаточность для карточки обращения
damage_description Описание заявителя Соответствие документам и вложениям
policy_number Указанный номер либо null Связь с записью в учётной системе

Учебный документ и эталон JSON

Все данные ниже вымышлены. JSON подготовлен как эталон для проверки: он не является результатом замера или гарантией ответа модели.

Учебное обращение DEMO-FNOL-42.
Дата: 01.10.2026.
Место: парковка магазина.
Описание: царапина на двери.
{
  "reported_date": {
    "value": "01.10.2026",
    "quote": "Дата: 01.10.2026."
  },
  "place": {
    "value": "парковка магазина",
    "quote": "Место: парковка магазина."
  },
  "damage_description": {
    "value": "царапина на двери",
    "quote": "Описание: царапина на двери."
  },
  "policy_number": {
    "value": null,
    "quote": null
  }
}

Подключение к API429

Выберите точный ID модели в каталоге, затем проверьте доступ своего ключа по GET /v1/models. Используйте тот же ключ и базовый URL, что и при генерации. Само наличие модели на сайте не подтверждает доступ конкретного ключа.

curl https://gateway.api429.com/v1/models \
  -H "Authorization: Bearer $API429_API_KEY"

Ключ храните в переменной окружения API429_API_KEY, выбранный ID — в API429_MODEL. Не записывайте секрет в исходник или журнал. Контракт запроса и примеры авторизации — в документации API429.

Запрос и проверка ответа

Возьмите полный пример Python с валидатором и замените в нём только эти две строки:

FIELDS = ('reported_date', 'place', 'damage_description', 'policy_number')
SOURCE = 'Учебное обращение DEMO-FNOL-42.\nДата: 01.10.2026.\nМесто: парковка магазина.\nОписание: царапина на двери.\n'

Запрос использует POST /v1/chat/completions с полями model, messages, max_tokens, stream. Пример выводит результат, прошедший структурные и текстовые проверки, и сам не создаёт записей в рабочей системе. Параметры специальных JSON-режимов выбранной модели проверяйте отдельно; код не предполагает их поддержку по одному имени модели.

Проверка отклоняет пропущенные и лишние ключи, неверные типы и значения без цитаты. Пара null/null допустима только как обозначение отсутствующих сведений. Даже дословная цитата не доказывает, что она относится к нужному полю: это проверяется на контрольных документах.

Проверка перед передачей в систему

Первый статус результата — «извлечено, требуется проверка». Система обращений должна отличать факт получения заявления от его оценки. Неполный JSON не должен создавать видимость полного claim-файла, а отсутствие номера полиса — автоматически означать отказ.

При нескольких сообщениях сохраняйте хронологию и основания изменений. Не объединяйте обращения только по похожему тексту повреждения: это могут быть разные события. Связь с полисом, состав документов и последующие решения проверяются в процессе страховой организации.

Какие ошибки включить в тестовую выборку

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

Повторы и стоимость обработки

Храните идентификатор и версию исходного документа, а также состояние обработки в своём приложении. После перезапуска не создавайте вторую запись для уже принятого результата. При 429 сначала изучите сообщение и баланс; повторяйте только временные ошибки с ограничением попыток. Неудачный разбор JSON и HTTP-ошибка требуют разных действий.

Выбирайте модель по своему набору документов, а не по названию семейства. Считайте цену принятого результата вместе с повторами и проверкой; текущие тарифы API429 и сравнение Gemini отделены от проверки качества. Сначала запустите небольшую размеченную выборку, затем расширяйте поток.

Частые вопросы

Определяет ли пример, является ли случай страховым?

Нет. Он структурирует сведения из заявления и не оценивает страховое покрытие, ответственность или выплату. Данные передаются на предусмотренную организацией проверку.

Что делать с противоречащими сообщениями?

Сохраняйте оба источника и их время. Не заменяйте спорное значение предположением модели; выделите конфликт для проверки оператором.

Источники и документация

  1. API429 — клиентский OpenAPI
  2. API429 — подключение и примеры
  3. Python — JSON
  4. Python — HTTP-запрос

Следующий шаг — на практике.

Перед интеграцией проверьте ID модели, актуальную цену и формат запроса. Доступность зависит от модели и маршрута провайдера.

Telegram