Izveidojiet AI API tālākpārdevēju portālu: īrnieku nodrošināšana, lietojuma mērīšana, norēķini un telegrammas pakalpojumi

Ja iepakojat AI piekļuvi klientiem, nenododiet viņiem savas iepriekšējās pakalpojumu sniedzēja atslēgas. Izveidojiet tālākpārdevēju slāni, kas izsniedz klienta darbības jomas atslēgas, ievieš īrnieku ierobežojumus pirms katra pieprasījuma, reģistrē lietojumu savā virsgrāmatā un sinhronizē norēķinu kopsummas ar jūsu norēķinu sistēmu.

Šajā rokasgrāmatā ir aprakstīts praktisks darbības modelis AI API aģentūrām, konsultantiem un SaaS veidotājiem. Tā nav klienta gadījuma izpēte. Tā ir atsauces arhitektūra, kuru varat pielāgot neatkarīgi no tā, vai izmantojat partnera API, iekšējo vārteju vai pielāgotu starpniekserveri vairāku modeļu nodrošinātāju priekšā.

Tālākpārdevēju portāla arhitektūra

Drošs tālākpārdevēju portāls nodala četrus pienākumus:

• Partneru administrēšana: jūsu iekšējā lietotne klientu, plānu, atslēgu, ierobežojumu un atbalsta darbplūsmu izveidei.
• Pieprasīt izpildi: vārtejas ceļš, kas autentificē klientu atslēgas, pārbauda politiku, maršrutē pieprasījumus un bloķē trafiku, kas pārsniedz ierobežojumu.
• Izlietojuma uzskaite: izturīga virsgrāmata, kas reģistrē pieprasījuma līmeņa lietojumu un cenu ievades datus.
• Norēķini un darbības: plānotā rēķinu sinhronizācija, brīdinājumi, paziņojumi par atslēgu rotāciju un atbalsta eskalācija.

Tipiska plūsma izskatās šādi:

Partnera administratora lietotne
  → Partnera API
    → klientu / darbvietas ieraksti
    → klienta darbības jomas API atslēgas
    → plāns, modelis, budžets un likmju ierobežojumi
    → pieprasījuma vārteja
    → lietošanas virsgrāmata
    → norēķinu sinhronizācija
    → Telegrammas paziņojumu robots

Fakts: OpenAI iesaka nekoplietot uz lietotāju balstītas API atslēgas sadarbībai un tā vietā izmantot uz projektiem balstītas atslēgas, piešķirtos dalībniekus un atšķirīgas atslēgas ar izolētiem likmes ierobežojumiem un tēriņu vadīklām. OpenAI pakalpojumu noteikumi arī aizliedz pirkt, pārdot vai nodot API atslēgas trešajai pusei vai no tās. Šie fakti atbalsta tālākpārdevēja dizainu, kurā augšupējie akreditācijas dati paliek servera pusē un klienti saņem jūsu pakārtotās atslēgas.

Ieteikums: izsniedziet vienu pakārtoto atslēgu katram klientam, projektam vai videi. Neizmantojiet vienu klienta atslēgu atkārtoti vairākiem gala klientiem. Neatklājiet iepriekšējā pakalpojuma sniedzēja akreditācijas datus dokumentācijā, pārlūkprogrammas kodā, mobilajās lietotnēs, žurnālos vai klientu atbalsta ziņojumos.

Īrnieka datu modelis

Īrnieka modelim ir skaidri jānorāda izolācija. Saglabājiet vismaz šos laukus:

partnera_id
klienta_id
darbvietas_id
api_key_id
plan_id
norēķinu_statuss
izdevumu_limits
likmes_limits
atļautie_modeļi
telegram_chat_id
usage_virsgrāmatas_id
izveidots_at
atjaunināts_at
atsaukts_at

Lielākā portālā pievienojiet laukus priekšapmaksas atlikumam, valūtai, nodokļu reģionam, rēķina klienta ID, atbalsta līmenim, ļaunprātīgas izmantošanas statusam un pagaidu ignorēšanai.

Klienta ieraksta piemērs

{
  "partner_id": "partner_123",
  "customer_id": "cust_acme",
  "workspace_id": "ws_prod",
  "plan_id": "growth_api",
  "billing_status": "aktīvs",
  "spend_limit": {
    "periods": "mēnesis",
    "hard_cap_usd": 500,
    "trauksmes_sliekšņi": [0,5, 0,8, 0,95]
  },
  "rate_limit": {
    "pieprasījumi_minūtē": 120,
    "tokens_per_day": 2000000
  },
  "allowed_models": ["fast-chat", "reasoning-standard"],
  "telegram_chat_id": "-1001234567890",
  "usage_ledger_id": "ledger_cust_acme"
}

Ieteikums: izmantojiet customer_id, workspace_id un api_key_id kā atsevišķus jēdzienus. Klientam var būt vairākas darbvietas, un katrai darbvietai var būt nepieciešamas atsevišķas ražošanas, inscenēšanas un izstrādes atslēgas. Tas ievērojami atvieglo atsaukšanu, atkļūdošanu un lietošanas attiecināšanu.

Jauna klienta uzņemšanas secība

Uzticama ieviešanas plūsma pēc konstrukcijas ir garlaicīga. Tam katru reizi ir jāveido tie paši ieraksti un jāatstāj audita pēdas.

1. Izveidojiet klientu: saglabājiet juridisko vārdu, uzvārdu, norēķinu kontaktpersonu, tehnisko kontaktpersonu un iekšējo īpašnieku.
2. Izveidojiet darbvietu: atdaliet ražošanu no testēšanas, ja klients integrēs programmatiski.
3. Piešķiriet plānu: definējiet iekļautos modeļus, uzcenojumu, norēķinu ātrumu un atbalsta cerības.
4. Iestatīt ierobežojumus: konfigurējiet tēriņu ierobežojumus, pieprasījumu ierobežojumus, pilnvaru ierobežojumus un sērijveida politiku.
5. Izveidot API atslēgas: izsniedziet tvēruma atslēgas klienta vidēm.
6. Nosūtiet integrācijas norādījumus: norādiet pamata URL, autentifikācijas formātu, modeļu sarakstu, ierobežojumus un atbalsta kanālu.
7. Iespējot brīdinājumus: pievienojiet Telegram vai citu operāciju kanālu, lai saņemtu paziņojumus par zemu atlikumu, atslēgu, pārtraukumiem un norēķiniem.
8. Palaidiet pārbaudes pieprasījumu: pārbaudiet autentifikāciju, lietojuma ierakstīšanu, piekļuvi modelim un rēķinu kartēšanu.

Ieteikums: padariet ieviešanu idempotentu. Ja jūsu administratora lietotne atkārtoti mēģina veikt klienta izveides darbību, tai nevajadzētu izveidot norēķinu ierakstu vai API atslēgu dublikātus. Izmantojiet ārējos ID un idempotences atslēgas zvanu nodrošināšanai.

Pieprasījuma laika budžeta kontrole

Svarīgākā izpilde tiek veikta, pirms pieprasījums sasniedz augšupējo modeli. Jūsu vārtejai nevajadzētu atklāt, ka klients ir pārsniedzis budžetu tikai pēc tam, kad pakalpojumu sniedzējs jau ir no jums iekasējis maksu.

Izmantojiet šo pirmslidojuma secību:

1. Autentificējiet pakārtoto API atslēgu.
2. Atrisiniet parametrus partner_id, customer_id un workspace_id.
3. Pārbaudiet, vai atslēga ir aktīva un nav atsaukta.
4. Pārbaudiet norēķinu statusu: aktīvs, izmēģinājuma periods, priekšapmaksa, apturēts, nokavēts vai apturēts.
5. Pārbaudiet pašreizējā norēķinu perioda tēriņu ierobežojumu.
6. Pārbaudiet ātruma ierobežojumus, piemēram, pieprasījumus minūtē un marķierus dienā.
7. Pārbaudiet, vai pieprasītais modelis ir atļauts klienta plānā.
8. Aprēķiniet maksimālās iespējamās izmaksas, izmantojot modeli, maksimālās pilnvaras un pieprasījuma parametrus.
9. Novirziet pieprasījumu tikai tad, ja politika tiek izturēta.

ja key.revoked:
    noraidīt(401, "API atslēga atsaukta")
ja customer.billing_status sadaļā ["paused", "suspended", "dedue"]:
    reject(402, "Norēķinu statuss neļauj izmantot")
ja requested_model nav iekļauts customer.allowed_models:
    reject(403, "Šai darbvietai modelis nav iespējots")
ja pašreizējais_periods_tēriņi + aptuvenās_maksimālās_izmaksas > customer.hard_cap:
    noraidīt(402, "Tēriņu limits pārsniegts")
ja likme_limit_pārsniegts(klienta_id, pieprasītais_modelis):
    noraidīt(429, "Likmes ierobežojums pārsniegts")
route_request()

Fakts: OWASP API drošības populārākie 10 2023. gada galvenie API riski norāda uz bojātu objektu autorizāciju, bojātu autentifikāciju un neierobežotu resursu patēriņu. Tie attiecas tieši uz tālākpārdevēju portāliem: viens nomnieks nedrīkst lasīt cita nomnieka datus, atslēgas nedrīkst būt apietas, un viens klients nedrīkst radīt neierobežotus pakalpojumu sniedzēja izdevumus.

Kompozīcija: stingri stingri ierobežojumi aizsargā jūsu rezervi, taču tie var pārtraukt likumīgu pieaugumu. Labs kompromiss ir pagaidu ignorēšanas darbplūsma ar derīguma termiņu, apstiprinātāju, iemeslu un audita žurnāla ierakstu.

Izmantojiet virsgrāmatu kā patiesības avotu

Lai nodrošinātu reāllaika piekļuves kontroli, saglabājiet savu lietošanas virsgrāmatu. Ārējie norēķinu rīki ir lieliski piemēroti rēķinu izrakstīšanai, taču tie parasti nav īstā vieta, lai pieņemtu milisekundes līmeņa atļaušanas vai noraidīšanas lēmumus.

Lietošanas notikumam ir jāietver pietiekami daudz informācijas, lai saskaņotu pakalpojumu sniedzēja rēķinus, izskaidrotu klientu rēķinus un atkļūdotu strīdus.

{
  "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",
  "modelis": "pamatojuma standarts",
  "input_tokens": 1850,
  "output_tokens": 420,
  "cached_tokens": 1200,
  "provider_cost": 0,0142,
  "reseller_price": 0,0230,
  "valūta": "USD",
  "laikspiedols": "2026-08-02T10:15:30Z",
  "statuss": "izdevies"
}

Ierakstiet arī neveiksmīgos pieprasījumus, taču nošķiriet kļūdas, par kurām jāmaksā, no kļūmēm, par kurām nav jāmaksā. Pakalpojumu sniedzēja taimautiem, validācijas kļūmēm, klientu atcelšanas gadījumiem, atkārtotiem mēģinājumiem un drošības blokiem var būt dažādi uzskaites rezultāti atkarībā no to rašanās brīža.

Ieteikums: ierakstiet neapstiprinātu virsgrāmatas notikumu, kad pieprasījums ir pieņemts, un pēc tam pabeidziet to, kad ir zināms marķiera lietojums un izmaksas. Tas ļauj rezervēt budžetu pirms maršrutēšanas un pēc tam labot galīgo summu pēc pabeigšanas.

Saskaņošanas modelis

1. Saglabājiet pieprasījuma līmeņa notikumus iekšējā virsgrāmatā.
2. Apkopots lietojums pēc klienta, modeļa un norēķinu perioda.
3. Salīdziniet iekšējās kopsummas ar iepriekšējiem pakalpojumu sniedzēju rēķiniem vai lietojuma eksportu.
4. Pirms rēķinu izrakstīšanas izpētiet būtiskās atšķirības.
5. Sinhronizējiet apkopoto apmaksājamo lietojumu ar norēķinu sistēmu.

Kompozīcija: apkopotā lietojuma sinhronizēšana samazina norēķinu notikumu apjomu un sarežģītību, taču var padarīt klientu rēķinus mazāk detalizētus. Ja klientiem ir nepieciešami modeļa vai projekta līmeņa pārskati, saglabājiet šīs kategorijas savā norēķinu sinhronizācijā vai klientu informācijas panelī.

Norēķinu sinhronizācija ar uz lietojumu balstītiem skaitītājiem

Uz lietojumu balstītās norēķinu sistēmas parasti darbojas saskaņā ar modeli: definē produktus un cenas, pārņem lietošanas notikumus, apkopo tos norēķinu periodā, ģenerē rēķinus un pārrauga kļūdas. Stripe Billing, piemēram, atbalsta skaitītāja notikumus ar notikuma nosaukumu, klienta identifikatoru, skaitlisko vērtību, izvēles laikspiedolu, neobligātu idempotences identifikatoru un izvēles izmēriem.

AI API norēķiniem izplatītākās skaitītāju izvēles ir šādas:

• Tokenu kopsumma: noderīga, ja cenas ir cieši saistītas ar ievades un izvades marķieriem.
• Pieprasījumu skaits: noderīga vienkāršiem plāniem vai zema līmeņa API izsaukumiem.
• Modeļiem raksturīgās vienības: noderīgas, ja augstākās kvalitātes modeļiem ir atšķirīgas rezerves.
• Sēdvietas vai aktīvās darbvietas: noderīgas hibrīdiem SaaS-plus lietošanas plāniem.

Fakts: svītru mērītāji atbalsta tādas apkopošanas formulas kā summa, skaits un pēdējais. Tie ir saistīti ar marķieru kopsummu, pieprasījumu skaitu un stāvoklim līdzīgām vērtībām, piemēram, vietām vai aktīviem ierobežojumiem.

Ikdienas norēķinu sinhronizēšana var radīt šādus skaitītāja notikumus:

{
  "notikuma_nosaukums": "ai_tokens_used",
  "klients": "stripe_customer_456",
  "vērtība": 2270000,
  "laikspiedols": "2026-08-02T23:59:00Z",
  "idempotency_key": "cust_acme_2026-08-02_tokens",
  "izmēri": {
    "plāns": "growth_api",
    "model_family": "standarta"
  }
}

Ieteikums: saglabājiet iekšējo virsgrāmatu detalizētāku nekā rēķinu. Varat izrakstīt ikdienas marķiera kopsummas, vienlaikus saglabājot pieprasījuma līmeņa ierakstus atbalstam, krāpšanas pārskatīšanai, likmes ierobežojumu regulēšanai un maržas analīzei.

Telegrammas darbības, nepadarot Telegram par ierakstu sistēmu

Telegramma ir noderīga ātrai operatora darbplūsmai: atbalsta komandas jau pamana ziņojumus, robotprogrammatūra var sūtīt brīdinājumus, un klienti var saņemt instrukcijas par iekļaušanu, nepiesakoties informācijas panelī. Taču Telegram nevajadzētu būt vienīgajai audita izsekojamībai norēķinu, drošības vai atbalsta lēmumu pieņemšanai.

Labās Telegram darbplūsmās ietilpst:

• Brīdinājumi par zemu bilanci vai lieliem tēriņiem 50%, 80% un 95% no maksimālā apjoma.
• Jaunu klientu uzņemšanas ziņojumi ar dokumentācijas saitēm un maskētiem atslēgu nosaukumiem.
• API atslēgas rotācijas paziņojumi pirms un pēc pagriešanas.
• Pakalpojumu sniedzēja darbības pārtraukumu vai degradēta modeļa brīdinājumi.
• Cilvēka atbalsta eskalācija, kad klients atkārto 401., 402., 403. vai 429. kļūdas.

Fakts: Telegram Bot API izsaukumi tiek veikti, izmantojot HTTPS, uz robotu marķiera galapunktiem, un Telegram tīmekļa aizķerēs var būt ietverta slepenā marķiera galvene, kas palīdz pārbaudīt tīmekļa aizķeres izcelsmi.

Ieteikums: saglabājiet Telegram tērzēšanas ID kā nomnieka metadatus, taču neatklājiet tos klientiem. Reģistrējiet katru robota aktivizēto administratīvo darbību iekšējā audita žurnālā, norādot dalībnieku, laikspiedolu, klientu, veco vērtību, jauno vērtību un iemeslu.

Drošības un izolācijas kontrolsaraksts

Pirms pārdodat piekļuvi, pārbaudiet nomnieka izolāciju tā, it kā klients aktīvi mēģinātu pārkāpt robežas.

• Klients A nevar skatīt klienta B API atslēgas.
• Klients A nevar skatīt klienta B lietojumu, rēķinus, ierobežojumus, Telegram tērzēšanas ID vai norēķinu statusu.
• Atsauktā atslēga nekavējoties neizdodas visos pieprasījuma ceļos.
• Klients, kura norēķinu termiņš ir apturēts, nevar turpināt tērēt, izmantojot kešatmiņas sesijas vai vecās atslēgas.
• Klients nevar pieprasīt modeļus ārpus piešķirtā plāna.
• Cenu ierobežojumi attiecas uz klientu un darbvietu, nevis tikai uz globālo IP adresi.
• Tīmekļa aizķeres apstrādātāji pārbauda parakstus vai slepenās galvenes, ja tās tiek atbalstītas.
• Visi nodrošinājumi, ierobežojumu izmaiņas, atslēgu rotācijas un norēķinu ignorēšana veido audita žurnāla ierakstus.
• Atkārtoti mēģinājuma loģika izmanto idempotences atslēgas, lai dublēti pieprasījumi klientiem neizraksta dubultu rēķinu.
• Atbalsta rīki maskē noslēpumus un ierobežo, kas var atklāt vai pagriezt atslēgas.

Prognoze: tālākpārdevēju portāli arvien vairāk konkurēs par pārvaldību un norēķinu skaidrību, ne tikai par piekļuvi daudziem modeļiem. Kā standarta funkcijas klienti sagaida lietojumu katram projektam, skaidrus rēķinus, ātru atslēgu rotāciju un stingras tēriņu kontroles.

Galvenie kompromisi, kas jāizlemj agri

Priekšapmaksa salīdzinājumā ar pēcapmaksu

Priekšapmaksas atlikumi samazina kredītrisku un padara stingrus ierobežojumus vienkāršus, taču klientiem var nepatikt pārtraukumi. Pēcapmaksas norēķini ir raitāki pieredzējušiem klientiem, taču tam ir nepieciešama kredīta pārbaude, brīdināšanas darbplūsmas un spēcīgāka anomāliju noteikšana.

Viena jaukta cena salīdzinājumā ar modelim specifisku cenu

Jauktu cenu ir vieglāk izskaidrot. Modeļiem specifiska cenu noteikšana aizsargā peļņas normas un veicina efektīvu modeļu izvēli. Ja piedāvājat daudz modeļu, publicējiet vienkāršu klientam paredzētu modeļu katalogu un paslēpiet nevajadzīgo pakalpojumu sniedzējam raksturīgo sarežģītību.

Reāllaika mērīšana salīdzinājumā ar aizkavētu norēķinu

Reāllaika mērīšana nodrošina tēriņu ierobežojumus un priekšapmaksas atlikumus. Tam nepieciešama arī ilgstoša rakstīšana, atkārtošanas apstrāde un saskaņošana. Atliktais norēķins ir vienkāršāks, taču tas pakļauj jums pārmērīgus tēriņus, pirms ierobežojumi stājas spēkā.

Telegram-first atbalsts salīdzinājumā ar informācijas paneļa atbalstu

Telegram ir ātra un pazīstama daudziem operatoriem. Informācijas panelis ir labāks pārbaudāmībai, eksportam, atļaujām un klientu pašapkalpošanās nodrošināšanai. Izmantojiet telegrammu paziņojumiem un apstiprinājumiem, bet saglabājiet kanonisko ierakstu savā sistēmā.

Rīcāms izlaišanas plāns

1. Sāciet ar nomnieka izolāciju: pirms papildu norēķinu funkciju pievienošanas ieviesiet klienta, darbvietas, atslēgas, plāna un ierobežojumu ierakstus.
2. Izveidojiet pirmslidojuma izpildi: pirms maršrutēšanas bloķējiet atsauktas atslēgas, apturētus norēķinus, neatļautus modeļus un ierobežojiet trafiku.
3. Izveidojiet lietojuma virsgrāmatu: ierakstiet pieprasījumu ID, pilnvaru skaitu, izmaksas, tālākpārdevēju cenas, statusus, laikspiedolus un idempotences atslēgas.
4. Pievienot saskaņošanu: pirms rēķina izrakstīšanas salīdziniet iekšējo lietojumu ar kopējo pakalpojumu sniedzēja apjomu.
5. Sinhronizēt norēķinu kopsavilkumus: nosūtiet dienas vai stundas apkopojumus uz savu norēķinu platformu, izmantojot stabilas klientu kartēšanas un idempotences atslēgas.
6. Wire Telegram brīdinājumi: sāciet ar zema bilances, pārtraukuma, atslēgas rotācijas un atbalsta eskalācijas ziņojumiem.
7. Palaidiet izolācijas testus: pārbaudiet, vai neviens klients nevar piekļūt cita klienta atslēgām, lietojumam, ierobežojumiem, rēķiniem vai tērzēšanas metadatiem.

Tālākpārdevēju portāls nav tikai AI API iesaiņojums. Tas ir darbības slānis autentifikācijai, nomnieku politikai, lietojuma analīzei, norēķiniem un atbalstam. Vispirms izveidojiet virsgrāmatu un ierobežojumus, saglabājiet iepriekšējās atslēgas servera pusē un padariet katru klientam pieejamo atslēgu atsaucamu, tvēramu un attiecināmu.

Saistīta informācija

• PIAKLE-Isolation-limitsse"> galvenās izolācijas un rotācijas prakses
• AI API izmaksu kontroles metodes
• Kļūmes apzinoša maršrutēšana un atkārtojumi