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

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

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

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

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

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

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

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

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

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

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

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

partner_id
customer_id
workspace_id
api_key_id
plan_id
състояние_на_фактуриране
разходи_лимит
скорост_лимит
позволени_модели
telegram_chat_id
usage_ledger_id
created_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, "предупредителни_прагове": [0,5, 0,8, 0,95] }, "limit_rate": { "заявки_на_минута": 120, "токени_на_ден": 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. Изпълнете тестова заявка: проверете автентификацията, записа на използването, достъпа до модела и съпоставянето на фактури.

Recommendation: make onboarding idempotent. If your admin app retries a “create customer” operation, it should not create duplicate billing records or duplicate API keys. Use external IDs and idempotency keys for provisioning calls.

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

The most important enforcement happens before the request reaches an upstream model. Your gateway should not discover that a customer is over budget only after the provider has already charged you.

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

1. Удостоверете низходящия API ключ.
2. Resolve partner_id, customer_id, and workspace_id.
3. Check whether the key is active and not revoked.
4. Check billing status: active, trialing, prepaid, paused, overdue, or suspended.
5. Check hard spend cap for the current billing period.
6. Проверете ограниченията на скоростта, като заявки на минута и токени на ден.
7. Check whether the requested model is allowed for the customer’s plan.
8. Оценете максималната възможна цена от модела, максималните токени и параметрите на заявката.
9. Маршрутизирайте заявката само ако правилата са одобрени.

if key.revoked:
    отхвърляне (401, "API ключът е отменен")
if customer.billing_status в ["paused", "suspended", "prosterdue"]:
    reject(402, "Състоянието на фактуриране не позволява използване")
ако requested_model не е в customer.allowed_models:
    reject(403, "Моделът не е активиран за това работно пространство")
ако текущ_период_разход + прогнозна_максимална_цена > customer.hard_cap:
    reject(402, "Ограничението на разходите е надвишено")
if rate_limit_exceeded(customer_id, requested_model):
    отхвърляне (429, "Превишено ограничение на скоростта")
route_request()

Факт: Топ 10 на сигурността на API на OWASP за 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", "модел": "разсъждение-стандарт", "input_tokens": 1850, "output_tokens": 420, "cached_tokens": 1200, "provider_cost": 0.0142, "reseller_price": 0,0230, "currency": "USD", "клеймо": "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", "стойност": 2270000, "клеймо": "2026-08-02T23:59:00Z", "idempotency_key": "cust_acme_2026-08-02_tokens", "размери": { "план": "растеж_api", "model_family": "стандартен" } }

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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