ChatGPT API для SaaS-приложения: безопасная серверная интеграция

Архитектура: браузер не должен видеть ключ

Клиентское приложение отправляет только пользовательский ввод на ваш backend по уже существующей авторизации. Backend проверяет размер, роль, квоту и допустимый сценарий, после чего вызывает API собственным ключом из secret store. Ответ возвращается в нормализованном виде, а не вместе с техническими заголовками или диагностическими данными поставщика.

Никогда не помещайте RUSSIAAPI_API_KEY в JavaScript bundle, mobile-приложение, localStorage, форму поддержки или публичный пример. Нельзя просить пользователя вставить upstream key, cookie, пароль или код подтверждения. Утечка серверного ключа — повод сразу отозвать его, проверить журнал и выдать новый, а не просто скрыть строку в репозитории.

Разделите ключи, проекты и бюджеты

Создайте отдельные ключи для development, staging и production; если это поддерживает ваш контур, отделите ключи также по продукту или юридическому владельцу расходов. Это позволяет быстро остановить один маршрут, не выключая весь SaaS. Храните связь ключа с проектом в защищённой конфигурации, а в аналитике используйте короткий внутренний идентификатор, не секрет.

Задайте собственный дневной или месячный лимит, предупреждение на пороге и действие после превышения: очередь, отказ с понятным сообщением или ручная проверка. Лимит — ваш механизм контроля, а не характеристика модели. Цена, единица биллинга, скидка и доступность меняются, поэтому подтверждайте их в актуальной консоли и договоре перед расчётом unit economics.

Минимальный server-side маршрут

Обработчик должен валидировать вход до вызова модели: тип сообщения, максимальную длину, tenant и разрешённый model ID. Введите deadline, чтобы зависший запрос не занял worker навсегда, и ограничьте параллелизм на пользователя. Для операций с побочным эффектом используйте собственный idempotency key и не повторяйте их автоматически после обрыва.

Сохраняйте request ID вашего приложения, код результата, длительность и счётчик токенов только если он возвращён контрактом. Не записывайте исходный prompt по умолчанию. Если отладка необходима, используйте согласованный обезличенный sample, краткий срок хранения и доступ только у назначенной команды.

Тестируйте контракт до пользовательского трафика

Соберите набор из 12–20 безопасных сценариев: короткий запрос, русскоязычный ввод, слишком длинный ввод, недопустимый model ID, timeout, отмена и ошибка авторизации вашего маршрута. Для каждого задайте ожидаемый класс ответа, а не «идеальный текст». Прогоняйте набор при обновлении SDK, смене base URL или model ID.

Проверяйте качество отдельным eval-набором: точность по вашим критериям, долю отказов, формат JSON и случаи, когда модель должна честно сообщить об ограничении. Не превращайте один удачный demo в гарантию качества. Результат модели может меняться, поэтому release должен иметь feature flag, наблюдаемость и путь к откату.

Очереди, streaming и ошибки

Streaming полезен для интерфейса, но разрыв соединения не доказывает, что серверная операция не началась. Отделяйте чтение события от создания состояния: сохраняйте внутренний operation ID до stream, а при переподключении запрашивайте безопасный статус своего backend. Не предполагайте поддержку Last-Event-ID, пока не подтвердили её тестом и документацией конкретного endpoint.

Для 429, 5xx и timeout используйте ограниченное число повторов с jitter только для безопасных операций. Уважайте фактические коды и заголовки, не придумывайте фиксированные квоты. Если риск, расход или доля ошибок растут, поставьте очередь на паузу и разберите причину вместо бесконечного retry.

Проверка перед production

• Ключ находится только на сервере и изолирован по среде.
• Backend проверяет пользователя, размер, модель и квоту.
• Есть бюджетный alert, deadline и контролируемый отказ.
• Логи не содержат ключей, prompts и полных заголовков.
• Каталог, договор и data flow подтверждены на дату запуска.

Этот список не подтверждает соответствие требованиям автоматически. Он помогает собрать проверяемые инженерные доказательства, с которыми владелец данных и юрист смогут рассмотреть конкретный сценарий SaaS.

Server-side пример

Пример показывает минимальную форму проверки: ключ берётся только из окружения, вход валидируется на сервере, а недокументированные возможности не предполагаются. Перед запуском подтвердите маршрут и model ID в текущем каталоге RussiaAPI.

import OpenAI from 'openai';

const api = new OpenAI({ apiKey: process.env.RUSSIAAPI_API_KEY, baseURL: process.env.RUSSIAAPI_BASE_URL, timeout: 15_000 });
const allowedModels = new Set((process.env.ALLOWED_MODELS ?? '').split(',').filter(Boolean));

export async function answerForTenant({ tenantId, model, text }) {
  if (!tenantId || !allowedModels.has(model)) throw new Error('model_not_allowed');
  if (typeof text !== 'string' || text.length < 1 || text.length > 8_000) throw new Error('invalid_input');
  await assertTenantQuota(tenantId); // your DB-backed quota; no secrets in logs
  const response = await api.chat.completions.create({
    model, messages: [{ role: 'user', content: text }], max_tokens: 500,
  });
  return { id: response.id ?? null, text: response.choices?.[0]?.message?.content ?? '' };
}

async function assertTenantQuota(tenantId) { if (String(tenantId).length > 80) throw new Error('invalid_tenant'); }

Проверьте синтаксис через node --check, добавьте аутентификацию своего маршрута, rate limit и негативные тесты. Не логируйте тело запроса и заголовки только ради отладки.

Граница ответственности и безопасный запуск

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

Создавайте ключи RussiaAPI по принципу минимальных прав, храните их только в server-side secret store и ротируйте при смене сотрудника или подозрении на утечку. Перед production включите журналы без Authorization-заголовков, лимит расходов, таймауты и понятный путь остановки трафика.