Создайте портал реселлера AI API: подготовка арендаторов, измерение использования, выставление счетов и управление Telegram

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

В этом руководстве описана практическая операционная модель AI API для агентств, консультантов и разработчиков SaaS. Это не исследование ситуации с клиентом. Это эталонная архитектура, которую вы можете адаптировать независимо от того, используете ли вы партнерский API, внутренний шлюз или собственный прокси-сервер для нескольких поставщиков моделей.

Архитектура портала реселлера

Надежный портал реселлера разделяет четыре обязанности:

Типичный процесс выглядит так:

Приложение для администратора партнера
  → Партнерский API
    → записи клиентов/рабочих мест
    → ключи API на уровне клиента
    → план, модель, бюджет и ограничения ставок
    → запросить шлюз
    → журнал использования
    → синхронизация платежей
    → Бот уведомлений Telegram

Факт: OpenAI рекомендует не делиться пользовательскими ключами API для совместной работы, а вместо этого использовать ключи на основе проектов, назначенных участников и отдельные ключи с изолированными ограничениями скорости и контролем расходов. Условия услуг OpenAI также запрещают покупку, продажу или передачу ключей API третьей стороне или от нее. Эти факты подтверждают концепцию реселлера, при которой учетные данные исходящего уровня остаются на стороне сервера, а клиенты получают ваши собственные ключи нижестоящего уровня.

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

Модель данных арендатора

В модели арендатора изоляция должна быть явной. Сохраните как минимум эти поля:

partner_id
customer_id
идентификатор рабочей области
api_key_id
план_ид
биллинг_статус
потратить_лимит
тариф_лимит
разрешенные_модели
telegram_chat_id
use_ledger_id
создано_at
обновлено_at
revoked_at

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

Пример записи клиента

{
  "partner_id": "partner_123",
  "customer_id": "cust_acme",
  "workspace_id": "ws_prod",
  "plan_id": "growth_api",
  "billing_status": "активен",
  "spend_limit": {
    "период": "месяц",
    "hard_cap_usd": 500,
    «alert_thresholds»: [0,5, 0,8, 0,95]
  },
  "rate_limit": {
    «запросы_в_минуту»: 120,
    "tokens_per_day": 2000000
  },
  "allowed_models": ["быстрый чат", "стандарт рассуждения"],
  "telegram_chat_id": "-1001234567890",
  "usage_ledger_id": "ledger_cust_acme"

Рекомендация: рассматривайте customer_id, workspace_id и api_key_id как отдельные понятия. У клиента может быть несколько рабочих пространств, и для каждого рабочего пространства могут потребоваться отдельные ключи производства, подготовки и разработки. Это значительно упрощает отзыв, отладку и атрибуцию использования.

Последовательность действий для нового клиента

Надежный процесс адаптации изначально скучен. Он должен каждый раз создавать одни и те же записи и оставлять контрольный журнал.

Рекомендация: сделайте адаптацию идемпотентной. Если ваше приложение администратора повторяет операцию «создать клиента», оно не должно создавать дубликаты платежных записей или дубликаты ключей API. Используйте внешние идентификаторы и ключи идемпотентности для инициализации вызовов.

Контроль бюджета во время запроса

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

Используйте следующую последовательность предполетных проверок:

если key.revoked:
    отклонить (401, «Ключ API отозван»)
если customer.billing_status в ["приостановлено", "приостановлено", "просрочено"]:
    отклонить (402, «Состояние платежного статуса не позволяет использовать»)
если request_model нет в customer.allowed_models:
    отклонить (403, «Модель недоступна для этой рабочей области»)
если текущие_периодные_расходы + предполагаемая_максимальная_стоимость > customer.hard_cap:
    отклонить (402, «Превышен лимит расходов»)
еслиrate_limit_exceeded(customer_id, request_model):
    отклонить (429, «Превышен предел скорости»)
маршрут_запрос()

Факт: В рейтинге OWASP API Security Top 10 2023 года нарушение авторизации объектов, нарушение аутентификации и неограниченное потребление ресурсов названы основными рисками API. Они напрямую связаны с порталами реселлеров: один арендатор не должен читать данные другого арендатора, ключи нельзя обойти, а один клиент не должен иметь возможность создавать неограниченные расходы поставщика.

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

Реестр использования как источник достоверной информации

Для контроля доступа в режиме реального времени ведите собственный журнал использования. Внешние инструменты выставления счетов отлично подходят для выставления счетов, но обычно они не подходят для принятия решений о разрешении или запрете на уровне миллисекунд.

Событие использования должно охватывать достаточно деталей, чтобы сверять счета поставщиков, объяснять счета клиентов и устранять споры:

{
  "request_id": "req_01J...",
  "idempotency_key": "idem_abc123",
  "partner_id": "partner_123",
  "customer_id": "cust_acme",
  "workspace_id": "ws_prod",
  "api_key_id": "key_live_789",
  «модель»: «стандарт рассуждения»,
  «входные токены»: 1850,
  «выходные_токены»: 420,
  «cached_tokens»: 1200,
  «provider_cost»: 0,0142,
  «reseller_price»: 0,0230,
  "валюта": "доллар США",
  "timestamp": "2026-08-02T10:15:30Z",
  "статус": "успешно"

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

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

Шаблон сверки

Компромисс. Синхронизация сводных данных об использовании уменьшает объем и сложность событий выставления счетов, но может сделать счета клиентов менее подробными. Если клиентам нужны отчеты на уровне модели или проекта, сохраните эти параметры в синхронизации платежей или на информационной панели клиента.

Синхронизация платежей со счетчиками использования

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

Для выставления счетов через AI API обычно используются следующие варианты счетчиков:

Факт. Счетчики полосы поддерживают такие формулы агрегирования, как сумма, количество и последний. Они соответствуют общему количеству токенов, количеству запросов и значениям состояния, таким как количество мест или активные лимиты.

При ежедневной синхронизации счетов могут создаваться такие события счетчика:

{
  "event_name": "ai_tokens_used",
  "клиент": "stripe_customer_456",
  «значение»: 2270000,
  "timestamp": "2026-08-02T23:59:00Z",
  "idempotency_key": "cust_acme_2026-08-02_tokens",
  "размеры": {
    "plan": "growth_api",
    "model_family": "стандартный"
  }

Рекомендация: внутренняя книга должна быть более детальной, чем счет-фактура. Вы можете выставлять счета за ежедневные суммы токенов, сохраняя при этом записи на уровне запросов для поддержки, проверки мошенничества, настройки ограничения скорости и анализа маржи.

Операции Telegram без превращения Telegram в систему записи

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

Хорошие рабочие процессы Telegram включают в себя:

Факт. Вызовы API Telegram Bot выполняются через HTTPS к конечным точкам токенов бота, а веб-перехватчики Telegram могут включать секретный заголовок токена, помогающий проверить происхождение веб-перехватчика.

Рекомендация: храните идентификаторы чата Telegram как метаданные клиента, но не раскрывайте их другим клиентам. Записывайте каждое административное действие, инициированное ботом, в журнал внутреннего аудита с указанием исполнителя, отметки времени, клиента, старого значения, нового значения и причины.

Контрольный список безопасности и изоляции

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

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

Ключевые компромиссы, которые необходимо принять заранее

Предоплата и постоплата

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

Единая смешанная цена или цена для конкретной модели

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

Счет в режиме реального времени или отложенное выставление счетов

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

Поддержка в первую очередь в Telegram или поддержка в первую очередь в панели управления

Telegram быстр и знаком многим операторам. Панель мониторинга лучше подходит для проверки, экспорта, разрешений и самообслуживания клиентов. Используйте Telegram для уведомлений и одобрений, но сохраняйте каноническую запись в своей системе.

План действий

Портал реселлера – это не просто оболочка AI API. Это рабочий уровень для аутентификации, политики арендаторов, анализа использования, выставления счетов и поддержки. Сначала создайте реестр и ограничения, храните восходящие ключи на стороне сервера и сделайте каждый клиентский ключ отзывным, ограниченным и атрибутируемым.

Связанное чтение

• Изоляция и ротация ключей API практики
• Методы контроля затрат на AI API
• маршрутизация и повторные попытки с учетом сбоев