Команда закладывает в творческий пайплайн автоматический вызов к NovelAI, а на этапе интеграции выясняется, что для нужного шага нет задокументированного публичного эндпоинта. Стандартная реакция: посадить оператора, который в нужный момент открывает браузер, логинится и передаёт данные из активной сессии дальше по конвейеру. Ручной обход не решает архитектурную проблему, а маскирует её, и разбираться в этом стоит до реализации, а не после инцидента.
Позиция этого разбора проверяема: если публичный контракт NovelAI не подтверждает обязательный серверный шаг, шаг нужно исключить из архитектуры или переформулировать без session-обхода, а ручной handoff здесь не годится в качестве заплатки. Отсутствие контракта не становится контрактом оттого, что рядом появился человек с открытой вкладкой браузера, а зависимость, выстроенная так, рано или поздно оборачивается риском для аккаунта.
Дальше не обзор «есть ли у NovelAI API» и не инструкция по обходам, а postmortem несостоявшегося требования: каждый обязательный шаг пайплайна проверяется по четырём полям (публичный интерфейс, тип авторизации, правило автоматизации, документированный стоп-фактор), и результат фиксируется как запись с одним из трёх решений: подтверждённый серверный шаг, исключение из архитектуры, новый независимый сценарий.
Подключите AI-агентов с оплатой в рублях на provod.ai
Что вообще есть у NovelAI как публичный контракт?
Публичная поверхность NovelAI разбита на несколько несовместимых друг с другом контрактов, и первая ошибка проектирования: считать её одним API. Документация NovelAI (доступ 2026-07-18) описывает REST «Primary API» для логина, подписки, данных пользователя и историй, задокументированный через Swagger UI, а также отдельные специализированные генерационные API для текста и изображений со своими страницами документации. У каждого контракта свой адрес и своя модель авторизации, и путать их значит закладывать в архитектуру шаг, для которого пока ничего не подтверждено.
Авторизаций тоже две, и разница между ними определяет, что вообще можно автоматизировать. По документации сторонний разработчик пользовательского приложения обязан просить у конечного пользователя его собственный Persistent API Token, сгенерированный в настройках аккаунта, а не собирать логин с паролем: токен показывается один раз и после закрытия диалога не восстанавливается. Регенерация токена мгновенно инвалидирует предыдущий, и никакого механизма тихой автоматической ротации в документации нет, поэтому интеграция обязана обновлять сохранённый токен вручную при каждой регенерации.
Второй поток авторизации архитектурно самостоятелен: эндпоинт /login превращает логин и пароль в access key, а тот выдаёт access token сроком на 30 дней. Этот поток реализуют и документируют независимые клиентские библиотеки, например Aedial/novelai-api (доступ 2026-07-18), и он не тождествен выданному пользователем Persistent API Token, эту разницу нельзя терять при выборе, какой шаг считать поддерживаемым.
Третья вещь, которую часто ошибочно тащат в серверную автоматизацию: встроенный Scripting API v1. Это внутриклиентный скриптинг для лорбуков, документов и историй со своей моделью разрешений (documentEdit, storyEdit, fileDownload, clipboardWrite и другие), и по документации он выполняется внутри активной залогиненной клиентской сессии. Нигде он не описан как удалённо вызываемый, внешне аутентифицируемый эндпоинт: если обязательный шаг пайплайна молча опирается на Scripting v1 «где-то на сервере», session-зависимость в архитектуре уже есть, просто она пока не названа своим именем.
Если после этого разбора у читателя остаётся отдельный, уже подтверждённый модельный шаг (например, генерация текста через совместимый эндпоинт), его можно вынести в provod.ai как в российский каталог совместимых моделей, но это будет отдельный сценарий, а не продолжение и не обход правил NovelAI.
Почему ручной handoff не закрывает пробел
Логика ручного handoff кажется рациональной: раз API не отдаёт нужный шаг, пусть его выполнит оператор в интерфейсе, а автоматика подхватит результат. На деле пробел не закрывается, а маскируется: в архитектуре требование по-прежнему звучит как «серверный шаг X выполняется автоматически», хотя выполняет его человек в браузере с живой сессией. Контракта как не было, так и нет, появилась только видимость, что он есть.
Дальше эта видимость дорого обходится. Handoff, завязанный на активную сессию, тянет за собой следующий шаг: «пусть оператор один раз отдаст свои session-данные скрипту, чтобы не сидеть вручную». Это уже прямое нарушение правил: ToS NovelAI (обновлены 8 декабря 2025) отдельно запрещают делиться учётными данными аккаунта и предоставлять третьим лицам удалённый доступ к аккаунту (пункты 8.1 и 5.3.2), и извлечение приватных session-cookie ради «автоматизации» — именно та граница, за которую заходить нельзя.
Есть и вторая цена, менее очевидная: пока шаг числится «функцией продукта», его закладывают в SLA, в оценки сроков, в обещания клиенту. По факту это ручная операция без поддерживаемого контракта, которая ломается при любом изменении на стороне NovelAI: от обновления правил до регенерации токена, мгновенно инвалидирующей предыдущий. Поэтому решение по умолчанию «сохранить неподтверждённый шаг через ручной handoff» я считаю неверным: оно оставляет архитектурный долг невидимым для тех, кто принимает решения.
Честная развилка здесь только одна: либо у шага есть публичный контракт, и тогда он остаётся серверной функцией, либо контракта нет, и тогда шаг исключается из архитектуры или переписывается как новый независимый сценарий, подтверждённый сам по себе. Третьего варианта с ручной подпоркой на живой сессии не существует.
Как выглядит postmortem-record несостоявшегося требования
Метод устроен как проверка одного обязательного шага, а не как аудит всего NovelAI. Берёшь конкретное требование workflow, разбиваешь его на минимальные серверные шаги и каждый прогоняешь по четырём полям: публичный интерфейс, тип авторизации, правило автоматизации, документированный стоп-фактор. Если хотя бы одно поле не заполняется публичным фактом, шаг не подтверждён.
Здесь нужна оговорка про честность источников. Ни официальная документация, ни ToS, ни независимый клиент не описывают отдельного поддерживаемого эндпоинта для действий, которым нужен аутентифицированный браузерный cookie вместо Persistent API Token или login-derived access token. Из этого следует вывод, что для session-зависимого шага контракта нет, но это именно вывод из отсутствия, а не позитивное заявление NovelAI о том, что такого контракта не существует и не будет. Разработчик обязан прогнать через ту же проверку свой конкретный шаг: этот факт-пак верифицирует общую архитектуру и правила, а не чьё-то частное требование в пайплайне.
Запись postmortem удобно вести как строку: «требование workflow — обязательный серверный шаг — публичный интерфейс/правило — пробел — решение закрыть или перепроектировать». Такая строка не даёт спрятать пробел за формулировкой: когда рядом стоит конкретный интерфейс и конкретное правило, «мы это как-нибудь автоматизируем» перестаёт быть допустимым ответом.
Ниже минимальный пример того, как разнести подтверждённый и неподтверждённый путь в коде. Подтверждённый путь использует токен, который пользователь выдал сам; неподтверждённого пути в коде просто нет, вместо него явный отказ.
import os import httpx
# Подтверждённый путь: пользователь сам выдал Persistent API Token. # Токен показывается один раз и не восстанавливается после закрытия диалога. NAI\_TOKEN = os.environ["NAI\_PERSISTENT\_TOKEN"]
def confirmed\_step(payload: dict) -> httpx.Response: return httpx.post( "https://api.novelai.net/...", # только задокументированный публичный маршрут headers={"Authorization": f"Bearer {NAI\_TOKEN}"}, json=payload, timeout=30, )
def unconfirmed\_step(\*\_args, \*\*\_kwargs): # Шаг требует активной браузерной сессии/cookie. # Публичного контракта нет -> не реализуем, не подпираем handoff. raise NotImplementedError( "Session-зависимый шаг снят с архитектуры: нет публичного контракта" )
Код здесь важен не строчками, а формой решения: неподтверждённый шаг не «отложен на потом», он превращён в явный отказ, который виден в ревью и в логах. Так требование нельзя тихо протащить обратно в архитектуру.
Что говорят правила и тарифы, и где системы падают по отдельности
Правила стоит читать буквально: именно они превращают «технически возможно» в «недопустимо». ToS NovelAI (обновлены 8 декабря 2025) запрещают ботнеты и автоматизированные системы, которые не уважают ограничения сервиса или создают чрезмерную нагрузку (пункт 9.1.6), а также прямо запрещают делиться учётными данными и предоставлять удалённый доступ к аккаунту. Отдельные корпоративные Terms of Use Anlatan (обновлены 6 марта 2025) запрещают использовать «robot, spider или иное автоматическое устройство» для доступа к самому сайту, включая скрейпинг и мониторинг веб-страницы: это отдельная граница от токенного API. Пункт 5.6 отдельно фиксирует, что Anlatan не хранит логин-данные, а ответственность за их безопасность несёт пользователь.
Оговорка на честность: обе правовые страницы датированы (декабрь 2025 и март 2025) и попадают в окно актуальности на 2026-07-18, но у NovelAI и Anlatan нет публичного change-log, поэтому перед реализацией их стоит перечитать на предмет тихой правки. Это не формальность: именно на правилах держится решение «можно или нельзя автоматизировать», и оно чувствительнее к изменениям, чем код.
Тарифы задают ещё одну ось ограничений. По документации подписки уровни Tablet ($10), Scroll ($15) и Opus ($25 в месяц) определяют размер контекста, включённые Anlas для генерации картинок и доступ к моделям, включая Opus-эксклюзивные. При этом ни одна официальная страница не публикует числовой rate limit для API: авторы сторонних клиентов лишь отмечают, что генерационные вызовы подчиняются rate-лимитам NovelAI, без конкретной цифры. Это неподтверждённая деталь, а не установленный лимит, и закладывать в архитектуру конкретное число нельзя.
Где падают отдельные подсистемы, видно на публичном status-page, и это прямое подтверждение раздельности контрактов. NovelAI отдельно мониторит Website, Image Generation, Text Generation, Login, Payments и Explore — архитектурно и операционно разные системы, способные отказать изолированно: например, 16 июля 2026 был сбой только Payments, устранённый в тот же день, без отказа Login или API в этом окне. Прямого прецедента про сбой именно session-автоматизации в источниках нет: инцидент с оплатами не про это, он лишь показывает, что подсистемы независимы друг от друга.
Как сравнить это с российской интеграцией, если шаг всё-таки переписан
Предположим, postmortem завершён, и один шаг переформулирован в новый независимый сценарий, скажем, «сгенерировать текстовый черновик через совместимый эндпоинт», без всякой привязки к сессии NovelAI. Тогда встаёт отдельный вопрос доступа из России, и здесь полезно сравнение архитектур. У NovelAI однопоставщицкая модель с двумя токенами и оплатой в долларах, и российскому интегратору к этому добавляется ещё и барьер оплаты и доступа.
Именно на этом переформулированном, уже подтверждённом шаге уместен provod.ai как отдельный российский каталог совместимых моделей, а не как подтверждение или обход правил NovelAI. Практическая разница для интегратора: provod.ai собирает Claude, GPT, Gemini, DeepSeek и Qwen в одном каталоге и даёт единый API, совместимый с SDK OpenAI и Anthropic, так что подключение сводится к смене ключа и base_url. Оплата идёт с одного рублёвого баланса российской картой, через СБП или по счёту, без VPN и иностранных карт, а цены на модели предлагаются без наценки provod.ai.
from openai import OpenAI
# Тот же клиент, другой ключ и base\_url — переписанный независимый шаг. client = OpenAI( api\_key=os.environ["PROVOD\_API\_KEY"], base\_url="https://api.provod.ai/v1", )
Для команды это добавляет ещё один практичный слой: общие рабочие пространства с участниками, общими API-ключами, одним балансом организации, командной оплатой, контролем расхода и бизнес-документами (договор, счёт, закрывающие). К чату здесь же добавляются генерация и редактирование изображений и видеоредактор, если переписанный творческий сценарий шире одного текстового вызова. Для работы с персональными данными важна ещё одна деталь под 152-ФЗ: защищённый российский контур маскирует прямые персональные идентификаторы до отправки запроса во внешнюю модель.
Решение: исключить, переписать или подтвердить
Метод сводится в одну таблицу решений, которая работает как регрессионный фиксатор: каждый обязательный шаг проходит по строкам, и результат фиксируется явно, чтобы формулировка «доделаем руками» не проскочила мимо ревью.
| Состояние шага | Публичный контракт | Session-данные | Решение | Принимаемая цена |
|---|---|---|---|---|
| Есть эндпоинт и токен пользователя | подтверждён | не нужны | Подтверждённый серверный шаг | нет |
| Нет публичного интерфейса | отсутствует | не проверяется | Исключить из архитектуры | сузить workflow |
| Нужен браузерный cookie/сессия | отсутствует | требуются | Исключить, не подпирать handoff | сузить workflow |
| Правила не разрешают автоматизацию | есть, но запрещён | не важно | Переписать как новый сценарий | переписать требование |
| Шаг можно выполнить иным подтверждённым путём | подтверждён иначе | не нужны | Новый независимый сценарий | переписать требование |
Логика за таблицей простая: критерии отклонения — отсутствие публичного интерфейса, необходимость session-данных, запрет автоматизации в правилах. Если срабатывает любой из них, шаг не остаётся серверной функцией, а принимаемая цена честного решения: сузить или переписать workflow. Это дешевле, чем оставить неподтверждённую зависимость в фундаменте продукта.
Разработчик, который набирает в поиске «novel ai api» и ждёт единый универсальный контракт под любую задачу, чаще всего получает именно такой развилочный ответ: контракт есть, но узкий и разделённый, и часть желаемых шагов в него не попадает. Понимание этой границы и есть ставка читателя: оно снижает риск нарушить правила сервиса и скомпрометировать аккаунт.
Чего этот разбор не решает
Этот разбор не утверждает, что у NovelAI нет API, и не описывает способов его обойти. Он говорит другое: часть шагов, которые команды по привычке считают функциями продукта, не имеет поддерживаемого контракта.
Проверка не заменяет чтение собственных требований команды. Ни один источник здесь не подтверждает и не опровергает конкретный шаг в чьём-то пайплайне, будь то «автоскачивание экспортов истории» или «автоуправление подпиской». Эти шаги нужно прогнать через тот же absence-check самостоятельно; здесь верифицирована только общая архитектура авторизации, правил и тарифов.
Метод не даёт числового rate-лимита и не должен: официально опубликованной цифры нет, а сторонняя характеристика «subject to rate limiting» не заменяет установленный лимит. Строить расчёт нагрузки на несуществующем числе — тот же архитектурный долг, только в другом месте.
И отдельно про provod.ai: он не подтверждает NovelAI API и не является обходом его правил. Это отдельный российский каталог совместимых моделей для заново сформулированного и подтверждённого модельного шага. Он не заменяет автоматизационные платформы, GigaChat, приватную или on-prem инфраструктуру, функции, доступные только по подписке вендора, и работу по внедрению.
FAQ
Можно ли использовать login-поток на 30 дней вместо Persistent API Token?
Такой поток архитектурно существует и реализован независимыми клиентами через /login и access key. Но для пользовательского приложения документация NovelAI прямо предписывает просить у пользователя его собственный Persistent API Token, а не собирать логин с паролем. Выбор потока — это в том числе выбор соответствия правилам.
Считается ли встроенный Scripting API v1 серверным контрактом?
Нет. По документации он выполняется внутри активной залогиненной клиентской сессии со своей моделью разрешений и нигде не описан как удалённо вызываемый внешне аутентифицируемый эндпоинт. Опора на него в серверной автоматизации создаёт скрытую session-зависимость.
Если шаг не подтверждён, почему нельзя один раз сделать его руками?
Разовый ручной шаг оператора в интерфейсе допустим как ручная операция. Недопустимо выдавать его за автоматическую серверную функцию в архитектуре и тем более передавать скрипту session-данные оператора: последнее прямо нарушает ToS о неразглашении учётных данных.
Гарантирует ли статус-страница, что API не упадёт вместе с оплатой?
Она показывает обратное: Login, Payments, Image/Text Generation, Website и Explore мониторятся раздельно и падают изолированно, как в случае со сбоем только Payments 16 июля 2026. Проектируй так, будто любая из подсистем может отказать отдельно.
provod.ai — переведите AI из тестов в постоянный процесс
Когда модели становятся частью ежедневной работы, важны единые доступы, понятная оплата и совместимый API: платформа объединяет эти элементы для команды и бизнеса.
В одном каталоге — актуальные модели для текста и медиа: GPT от OpenAI, Claude от Anthropic, Gemini от Google, Grok от xAI, DeepSeek, Qwen, GLM, Kimi и MiniMax; для изображений — Nano Banana 2 Pro и GPT Image; для видео — последние версии Seedance, Kling, Veo и Google Omni. Также доступны модели для reasoning, поиска, документов, эмбеддингов, музыки и аудио.
Постоянная работа строится на прозрачной цене: официальный тариф модели передаётся 1:1, без собственной наценки provod.ai.
Соберите рабочий AI-контур: форма регистрации · цены на модели · защита данных по 152-ФЗ · главная provod.ai
Источники
- NovelAI (Anlatan), Primary API docs, https://api.novelai.net/docs/ — доступ 2026-07-18.
- NovelAI (Anlatan), Account/Persistent API Token, https://docs.novelai.net/en/text/usersettings/account/ — доступ 2026-07-18.
- NovelAI (Anlatan), Scripting API reference, https://docs.novelai.net/en/scripting/api-reference/ — доступ 2026-07-18.
- NovelAI (Anlatan), Subscription, https://docs.novelai.net/en/subscription/ — доступ 2026-07-18.
- Anlatan Inc., Terms of Service (обновлены 8 декабря 2025), https://novelai.net/terms — доступ 2026-07-18.
- Anlatan Inc., Terms of Use (обновлены 6 марта 2025), https://anlatan.ai/termsofuse — доступ 2026-07-18.
- NovelAI (Anlatan), Status page, https://status.novelai.net/ — доступ 2026-07-18.
- Aedial (независимый разработчик), novelai-api, https://github.com/Aedial/novelai-api — доступ 2026-07-18.