Изградете портал за дистрибутори на AI API: Предоставяне на наемател, измерване на използването, фактуриране и операции на Telegram

Ако пакетирате AI достъп за клиенти, не им давайте ключовете на вашия доставчик нагоре по веригата. Изградете дистрибуторски слой, който издава ключове с обхват на клиента, налага ограничения за наематели преди всяка заявка, записва използването във вашата собствена книга и синхронизира общите суми за таксуване с вашата система за таксуване.

Това ръководство описва практически оперативен модел за AI API за агенции, консултанти и създатели на SaaS. Това не е казус от клиента. Това е референтна архитектура, която можете да адаптирате, независимо дали използвате партньор API, вътрешен шлюз или персонализиран прокси пред множество доставчици на модели.

Архитектурата на портала за дистрибутори

Сигурният портал за дистрибутори разделя четири отговорности:

• Партньорска администрация: вашето вътрешно приложение за създаване на клиенти, планове, ключове, ограничения и работни процеси за поддръжка.
• Налагане на заявка: пътят на шлюза, който удостоверява клиентските ключове, проверява правилата, маршрутизира заявките и блокира трафика с надвишен лимит.
• Отчитане на използването: трайна счетоводна книга, която записва входове за използване и ценообразуване на ниво заявка.
• Таксуване и операции: планирано синхронизиране на фактури, сигнали, известия за ротация на ключове и ескалация на поддръжката.

Типичният поток изглежда така:

Partner Admin App
  → Partner API
    → customer / workspace records
    → customer-scoped API keys
    → plan, model, budget, and rate limits
    → request gateway
    → usage ledger
    → billing sync
    → Telegram notification bot

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

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

Модел на данни на клиента

Моделът на наемателя трябва изрично да посочва изолацията. Съхранявайте поне тези полета:

partner_id
customer_id
workspace_id
api_key_id
plan_id
billing_status
spend_limit
rate_limit
allowed_models
telegram_chat_id
usage_ledger_id
created_at
updated_at
revoked_at

В по-голям портал добавете полета за предплатен баланс, валута, данъчен регион, клиентски идентификационен номер на фактура, ниво на поддръжка, състояние на злоупотреба и временни замени.

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

{
  "partner_id": "partner_123",
  "customer_id": "cust_acme",
  "workspace_id": "ws_prod",
  "plan_id": "growth_api",
  "billing_status": "active",
  "spend_limit": {
    "period": "month",
    "hard_cap_usd": 500,
    "alert_thresholds": [0.5, 0.8, 0.95]
  },
  "rate_limit": {
    "requests_per_minute": 120,
    "tokens_per_day": 2000000
  },
  "allowed_models": ["fast-chat", "reasoning-standard"],
  "telegram_chat_id": "-1001234567890",
  "usage_ledger_id": "ledger_cust_acme"
}

Препоръка: третирайте customer_id, workspace_id и api_key_id като отделни понятия. Един клиент може да има множество работни пространства и всяко работно пространство може да се нуждае от отделни производствени, етапни и развойни ключове. Това прави много по-лесно отмяната, отстраняването на грешки и приписването на използването.

Поредица за въвеждане на нов клиент

Надежден поток на включване е скучен по дизайн. Трябва да създава едни и същи записи всеки път и да оставя одитна следа.

1. Създайте клиента: юридическо име на магазина, контакт за фактуриране, технически контакт и вътрешен собственик.
2. Създайте работно пространство: отделете производството от тестването, ако клиентът ще интегрира програмно.
3. Задаване на план: дефиниране на включени модели, маркиране, ритъм на таксуване и очаквания за поддръжка.
4. Задаване на лимити: конфигуриране на ограничения на разходите, лимити на заявки, лимити на токени и правила за пакет.
5. Създайте API ключове: издайте ключове с обхват за среди на клиента.
6. Изпратете инструкции за интегриране: осигурете основен URL адрес, формат за удостоверяване, списък с модели, ограничения и канал за поддръжка.
7. Активиране на сигнали: свържете Telegram или друг оперативен канал за известия за ниско салдо, ключ, прекъсване и фактуриране.
8. Изпълнете тестова заявка: проверете автентификацията, записа на използването, достъпа до модела и съпоставянето на фактури.

Препоръка: направете идемпотентно включване. Ако вашето администраторско приложение опита отново операция „създаване на клиент“, то не трябва да създава дублиращи се записи за фактуриране или дублиращи се API ключове. Използвайте външни идентификатори и ключове за идемпотентност за осигуряване на повиквания.

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

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

Използвайте тази последователност преди полет:

1. Удостоверете ключа API надолу по веригата.
2. Разрешете partner_id, customer_id и workspace_id.
3. Проверете дали ключът е активен и не е отменен.
4. Проверете състоянието на таксуване: активно, пробно, предплатено, поставено на пауза, просрочено или спряно.
5. Проверете ограничението на твърдите разходи за текущия период на фактуриране.
6. Проверете ограниченията на скоростта, като заявки на минута и токени на ден.
7. Проверете дали исканият модел е разрешен за плана на клиента.
8. Оценете максималната възможна цена от модела, максималните токени и параметрите на заявката.
9. Маршрутизирайте заявката само ако правилото премине.

if key.revoked:
    reject(401, "API key revoked")

if customer.billing_status in ["paused", "suspended", "overdue"]:
    reject(402, "Billing status does not allow usage")

if requested_model not in customer.allowed_models:
    reject(403, "Model not enabled for this workspace")

if current_period_spend + estimated_max_cost > customer.hard_cap:
    reject(402, "Spend limit exceeded")

if rate_limit_exceeded(customer_id, requested_model):
    reject(429, "Rate limit exceeded")

route_request()

Факт: OWASP API Топ 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",
  "model": "reasoning-standard",
  "input_tokens": 1850,
  "output_tokens": 420,
  "cached_tokens": 1200,
  "provider_cost": 0.0142,
  "reseller_price": 0.0230,
  "currency": "USD",
  "timestamp": "2026-08-02T10:15:30Z",
  "status": "succeeded"
}

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

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

Образец на съгласуване

1. Съхранявайте събития на ниво заявка във вътрешната книга.
2. Общо използване по клиент, модел и период на фактуриране.
3. Сравнете вътрешните общи суми с фактури на доставчици нагоре по веригата или експортирани данни за използване.
4. Проучете съществените разлики, преди да издадете фактури.
5. Синхронизиране на обобщената таксувана употреба със системата за таксуване.

Компромис: синхронизирането на обобщената употреба намалява обема и сложността на събитията за фактуриране, но може да направи фактурите на клиентите по-малко подробни. Ако клиентите се нуждаят от отчитане на ниво модел или на ниво проект, запазете тези измерения в синхронизирането на таксуването или в таблото за управление на клиента.

Синхронизиране на таксуването с измерватели, базирани на потреблението

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

За таксуване с AI API обичайните възможности за избор на измервателен уред са:

• Общо токени: полезно, когато ценообразуването е тясно свързано с входни и изходни токени.
• Брой заявки: полезно за прости планове или API повиквания с нисък символ.
• Единици, специфични за модела: полезни, когато първокласните модели имат различни маржове.
• Места или активни работни пространства: полезни за хибридни планове за използване SaaS-plus.

Факт: Ивичните измервателни уреди поддържат формули за агрегиране като сума, брой и последно. Те се съпоставят с общите токени, броя на заявките и стойностите, подобни на състоянието, като места или активни лимити.

Ежедневното синхронизиране на таксуването може да създаде събития на брояча като това:

{
  "event_name": "ai_tokens_used",
  "customer": "stripe_customer_456",
  "value": 2270000,
  "timestamp": "2026-08-02T23:59:00Z",
  "idempotency_key": "cust_acme_2026-08-02_tokens",
  "dimensions": {
    "plan": "growth_api",
    "model_family": "standard"
  }
}

Препоръка: поддържайте вътрешната книга по-подробна от фактурата. Можете да фактурирате дневни общи суми на токени, като същевременно запазвате записи на ниво заявка за поддръжка, преглед на измами, настройка на лимита на скоростта и анализ на маржа.

Telegram операции, без да се прави Telegram системата на запис

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

Добрите Telegram работни процеси включват:

• Сигнали за нисък баланс или високи разходи при 50%, 80% и 95% от ограничението.
• Съобщения за включване на нови клиенти с връзки към документация и маскирани имена на ключове.
• API-известия за ротация на клавиши преди и след ротация.
• Прекъсване на доставчика или предупреждения за влошен модел.
• Ескалация на човешка поддръжка, когато клиент попадне на повтарящи се грешки 401, 402, 403 или 429.

Факт: Telegram Извикванията на бот API се правят през HTTPS към крайни точки на бот-токен и Telegram уебкукичките могат да включват заглавка на таен токен, за да помогнат за проверка на произхода на уебкукичката.

Препоръка: съхранявайте Telegram идентификатори на чат като метаданни на клиентите, но не ги излагайте на клиенти. Регистрирайте всяко административно действие, задействано от бот, във вашия регистър за вътрешен одит с актьор, клеймо за време, клиент, стара стойност, нова стойност и причина.

Контролен списък за сигурност и изолация

Преди да продадете достъп, тествайте изолацията на наемателя, сякаш клиентът активно се опитва да премине границите.

• Клиент A не може да види ключовете на клиент B API.
• Клиент А не може да преглежда използването, фактурите, лимитите, Telegram идентификаторите на чат или състоянието на таксуване от Клиент Б.
• Отменен ключ се проваля незабавно по всички пътища на заявка.
• Клиент с пауза за таксуване не може да продължи да харчи чрез кеширани сесии или стари ключове.
• Клиентът не може да изисква модели извън зададения план.
• Ограниченията на тарифите се прилагат според клиента и работното пространство, а не само според глобалния IP адрес.
• Манипулаторите на уебкукички проверяват подписи или тайни заглавки, когато се поддържат.
• Всички обезпечавания, промени в ограниченията, ротации на ключове и замени на таксуването създават записи в журнала за проверка.
• Логиката за повторен опит използва ключове за идемпотентност, така че дублиращите се заявки да не таксуват двойно клиенти.
• Инструментите за поддръжка маскират тайни и ограничават кой може да разкрива или върти ключове.

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

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

Предплатени срещу абонаментни

Предплатените салда намаляват кредитния риск и правят твърдите прекъсвания лесни, но клиентите може да не харесат прекъсванията. Таксуването с отложено плащане е по-плавно за установени клиенти, но изисква кредитни проверки, работни потоци за напомняне и по-задълбочено откриване на аномалии.

Една смесена цена срещу специфично за модела ценообразуване

Смесената цена е по-лесна за обяснение. Ценообразуването според модела защитава маржовете и насърчава ефективния избор на модел. Ако предлагате много модели, публикувайте прост каталог с модели, насочен към клиента, и скрийте ненужната сложност, специфична за доставчика.

Измерване в реално време срещу отложено таксуване

Измерването в реално време позволява ограничения на разходите и предплатени салда. Освен това изисква трайни записи, обработка на повторно възпроизвеждане и съгласуване. Отложеното таксуване е по-просто, но ви излага на безумни разходи, преди ограниченията да влязат в сила.

Telegram-първа поддръжка срещу табло-първа поддръжка

Telegram е бърз и познат за много оператори. Таблото за управление е по-добро за проверка, експортиране, разрешения и самообслужване на клиенти. Използвайте Telegram за известия и одобрения, но съхранявайте каноничния запис във вашата система.

Приложим план за внедряване

1. Започнете с изолиране на наемател: внедряване на записи за клиент, работно пространство, ключ, план и лимит, преди да добавите разширени функции за таксуване.
2. Изградете принудително прилагане преди полет: блокирайте анулирани ключове, спряно таксуване, непозволени модели и надвишаване на лимита на трафика преди маршрутизиране.
3. Създаване на книга за използване: записвайте идентификационни номера на заявки, брой токени, разходи, цени на дистрибутори, статуси, времеви клейма и ключове за идемпотентност.
4. Добавяне на съгласуване: сравнете вътрешното използване с общите суми на доставчика нагоре по веригата, преди да фактурирате.
5. Синхронизиране на обобщените данни за таксуване: изпращайте дневни или почасови обобщени данни към вашата платформа за таксуване със стабилни съпоставяния на клиенти и ключове за идемпотентност.
6. Кабелни Telegram сигнали: започват със съобщения за нисък баланс, прекъсване, ротация на ключове и ескалация на поддръжката.
7. Изпълнете тестове за изолация: проверете дали никой клиент няма достъп до ключовете, използването, лимитите, фактурите или метаданните за чат на друг клиент.

Порталът за дистрибутори не е просто обвивка около AI API. Това е оперативен слой за удостоверяване, политика за наемател, анализ на използването, таксуване и поддръжка. Първо изградете счетоводната книга и лимитите, запазете ключовете нагоре по веригата от страна на сървъра и направете всеки ключ, обърнат към клиента, отменим, с обхват и приписване.

Свързано четене

• API практики за изолиране и ротация на ключове
• AI API контрол на разходите техники
• маршрутизиране и повторни опити при откази