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

Задача интеграции
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 отделены от проверки качества. Сначала запустите небольшую размеченную выборку, затем расширяйте поток.
Частые вопросы
Определяет ли пример, является ли случай страховым?
Нет. Он структурирует сведения из заявления и не оценивает страховое покрытие, ответственность или выплату. Данные передаются на предусмотренную организацией проверку.
Что делать с противоречащими сообщениями?
Сохраняйте оба источника и их время. Не заменяйте спорное значение предположением модели; выделите конфликт для проверки оператором.
Источники и документация
Следующий шаг — на практике.
Перед интеграцией проверьте ID модели, актуальную цену и формат запроса. Доступность зависит от модели и маршрута провайдера.


