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

Договоры через API: извлечение условий и цитат в JSON

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

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

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

API можно подключить к извлечению условий договора: получить стороны, сроки и фрагменты текста для карточки CLM. Полезный результат — проверяемые значения с цитатами, а не неподтверждённое заключение о рисках. Ниже разобран вымышленный учебный документ; приведённые условия не являются рекомендацией для реального договора.

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

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

Схема полей

Поле Что извлекаем Что не заключаем из этого
parties Названные стороны Полномочия подписантов
term Дословное условие о сроке Действительность или окончание всех обязательств
termination_notice Формулировка уведомления Юридическую допустимость расторжения
penalty_clause Цитата либо null Отсутствие ответственности в целом

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

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

Учебный договор DEMO-C-42.
Стороны: Компания A и Компания B.
Срок: до 31.12.2026.
Уведомление о расторжении: за 30 дней.
{
  "parties": {
    "value": "Компания A и Компания B",
    "quote": "Стороны: Компания A и Компания B."
  },
  "term": {
    "value": "до 31.12.2026",
    "quote": "Срок: до 31.12.2026."
  },
  "termination_notice": {
    "value": "за 30 дней",
    "quote": "Уведомление о расторжении: за 30 дней."
  },
  "penalty_clause": {
    "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 = ('parties', 'term', 'termination_notice', 'penalty_clause')
SOURCE = 'Учебный договор DEMO-C-42.\nСтороны: Компания A и Компания B.\nСрок: до 31.12.2026.\nУведомление о расторжении: за 30 дней.\n'

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

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

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

Передавайте в CLM черновик полей с основаниями, а не готовый статус «договор согласован». Специалист сверяет текст и связанные документы по правилам своей организации. Значение null означает, что конкретный фрагмент не найден в переданном тексте; оно не доказывает отсутствие условия во всём пакете.

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

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

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

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

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

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

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

Это юридическая проверка договора?

Нет. Это технический этап извлечения текста в заданную структуру. Юридическое значение условий, их взаимосвязь и решение по документу оцениваются отдельно.

Можно ли отправить весь комплект документов одним запросом?

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

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

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

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

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

Telegram