Zgradite portal za preprodajalce API-ja AI: zagotavljanje najemnikov, merjenje uporabe, zaračunavanje in operacije Telegrama

Če za odjemalce pripravite dostop z umetno inteligenco, jim ne izročite svojih ključev ponudnika navzgor. Zgradite plast preprodajalca, ki izdaja ključe v obsegu stranke, uveljavlja omejitve najemnikov pred vsako zahtevo, beleži uporabo v vaši lastni knjigi in sinhronizira plačljive vsote z vašim sistemom za zaračunavanje.

Ta vodnik opisuje praktični model delovanja za API AI za agencije, svetovalce in graditelje SaaS. To ni študija primera stranke. To je referenčna arhitektura, ki jo lahko prilagodite, ne glede na to, ali uporabljate partnerski API, notranji prehod ali proxy po meri pred več ponudniki modelov.

Arhitektura portala preprodajalcev

Varni portal za preprodajalce ločuje štiri odgovornosti:

• Partnerska administracija: vaša interna aplikacija za ustvarjanje strank, načrtov, ključev, omejitev in delovnih tokov podpore.
• Uveljavljanje zahtev: prehodna pot, ki preverja pristnost ključev strank, preverja pravilnik, usmerja zahteve in blokira prekomerni promet.
• Računovodstvo uporabe: vzdržljiva knjiga, ki beleži uporabo na ravni zahtev in vnose cen.
• Obračunavanje in poslovanje: načrtovana sinhronizacija računov, opozorila, obvestila o menjavi ključev in eskalacija podpore.

Tipičen tok izgleda takole:

Partner Admin App
  → Partner API
    → zapisi strank/delovnega prostora
    → ključi API v obsegu stranke
    → omejitve načrta, modela, proračuna in stopnje
    → zahtevaj prehod
    → knjiga porabe
    → sinhronizacija obračunavanja
    → Telegramov bot za obvestila

Dejstvo: OpenAI priporoča, da za sodelovanje ne delite ključev API, ki temeljijo na uporabniku, in namesto tega uporabite ključe, ki temeljijo na projektu, dodeljene člane in ločene ključe z izoliranimi omejitvami stopnje in nadzorom porabe. Pogoji storitev OpenAI tudi prepovedujejo nakup, prodajo ali prenos ključev API tretji osebi ali od nje. Ta dejstva podpirajo zasnovo preprodajalca, kjer poverilnice navzgor ostanejo na strani strežnika, stranke pa prejmejo vaše lastne ključe na nižji stopnji.

Priporočilo: izdajte en spodnji ključ na stranko, projekt ali okolje. Ne uporabljajte znova enega ključa stranke v več končnih odjemalcih. Ne razkrivajte poverilnic zgornjega ponudnika v dokumentaciji, kodi brskalnika, mobilnih aplikacijah, dnevnikih ali sporočilih za podporo odjemalcem.

Podatkovni model najemnika

Model najemnika mora biti izolacija eksplicitna. Shranite vsaj ta polja:

partner_id
customer_id
workspace_id
api_key_id
plan_id
billing_status
omejitev_porabe
meja_stopnje
dovoljeni_modeli
telegram_chat_id
usage_ledger_id
created_at
posodobljen_at
revoked_at

Na večjem portalu dodajte polja za predplačniško stanje, valuto, davčno regijo, ID stranke računa, stopnjo podpore, stanje zlorabe in začasne preglasitve.

Primer zapisa stranke

{
  "partner_id": "partner_123",
  "customer_id": "cust_acme",
  "workspace_id": "ws_prod",
  "plan_id": "growth_api",
  "billing_status": "aktivno",
  "spend_limit": {
    "obdobje": "mesec",
    "hard_cap_usd": 500,
    "opozorilni pragovi": [0,5, 0,8, 0,95]
  },
  "hitrost_limit": {
    "zahteve_na_minuto": 120,
    "žetoni_na_dan": 2000000
  },
  "allowed_models": ["fast-chat", "reasoning-standard"],
  "telegram_chat_id": "-1001234567890",
  "usage_ledger_id": "ledger_cust_acme"
}

Priporočilo: obravnavajte customer_id, workspace_id in api_key_id kot ločene koncepte. Stranka ima lahko več delovnih prostorov in vsak delovni prostor morda potrebuje ločene produkcijske, uprizoritvene in razvojne ključe. To olajša preklic, odpravljanje napak in dodeljevanje uporabe.

Zaporedje vkrcanja za novo stranko

Zanesljiv tok vkrcanja je že po zasnovi dolgočasen. Vsakič mora ustvariti iste zapise in pustiti revizijsko sled.

1. Ustvarite stranko: shranite uradno ime, kontakt za obračun, tehnični kontakt in notranjega lastnika.
2. Ustvarite delovni prostor: ločite proizvodnjo od testiranja, če bo stranka integrirala programsko.
3. Dodelite načrt: definirajte vključene modele, oznake, kadenco zaračunavanja in pričakovanja podpore.
4. Nastavite omejitve: konfigurirajte omejitve porabe, omejitve zahtev, omejitve žetonov in pravilnik o izbruhu.
5. Ustvarite ključe API: izdajte ključe z obsegom za strankina okolja.
6. Pošljite navodila za integracijo: navedite osnovni URL, obliko preverjanja pristnosti, seznam modelov, omejitve in podporni kanal.
7. Omogoči opozorila: povežite Telegram ali drug operacijski kanal za obvestila o nizkem stanju, ključu, izpadu in zaračunavanju.
8. Izvedite preskusno zahtevo: preverite avtentikacijo, beleženje uporabe, dostop do modela in preslikavo računov.

Priporočilo: vključitev naj bo idempotentna. Če vaša skrbniška aplikacija znova poskusi operacijo »ustvari stranko«, ne bi smela ustvariti podvojenih zapisov za obračun ali podvojenih ključev API. Uporabite zunanje ID-je in ključe idempotence za zagotavljanje klicev.

Nadzor proračuna v času zahteve

Najpomembnejša uveljavitev se zgodi, preden zahteva doseže model navzgor. Vaš prehod ne bi smel ugotoviti, da je stranka presegla proračun, šele potem, ko vam je ponudnik že zaračunal.

Uporabite to zaporedje pred tiskom:

1. Preverite pristnost spodnjega ključa API-ja.
2. Razreši partner_id, customer_id in workspace_id.
3. Preverite, ali je ključ aktiven in ni preklican.
4. Preverite stanje zaračunavanja: aktivno, poskusno, predplačniško, zaustavljeno, zapadlo ali začasno ustavljeno.
5. Preverite zgornjo mejo porabe za trenutno obračunsko obdobje.
6. Preverite omejitve hitrosti, kot so zahteve na minuto in žetoni na dan.
7. Preverite, ali je zahtevani model dovoljen za strankin načrt.
8. Ocenite največjo možno ceno na podlagi modela, največjega števila žetonov in parametrov zahteve.
9. Usmeri zahtevo le, če je pravilnik sprejet.

if key.revoked:
    zavrni (401, "ključ API-ja preklican")
if customer.billing_status v ["paused", "suspended", "overdue"]:
    zavrni (402, "Stanje obračunavanja ne dovoljuje uporabe")
če requested_model ni v customer.allowed_models:
    zavrni (403, "Model ni omogočen za ta delovni prostor")
if current_period_spend + predicted_max_cost > customer.hard_cap:
    zavrni (402, "Omejitev porabe presežena")
if rate_limit_exceeded(customer_id, requested_model):
    zavrni (429, "Omejitev stopnje presežena")
route_request()

Dejstvo: OWASP API Security Top 10 2023 kot glavna tveganja API-ja navaja pokvarjeno avtorizacijo objektov, pokvarjeno preverjanje pristnosti in neomejeno porabo virov. Ti se preslikajo neposredno na portale preprodajalcev: en najemnik ne sme brati podatkov drugega najemnika, ključev ne sme biti mogoče obiti in ena stranka ne sme imeti možnosti ustvarjanja neomejene porabe ponudnika.

Kompromis: stroge trde omejitve ščitijo vašo maržo, vendar lahko prekinejo zakonite skoke. Dober kompromis je začasna preglasitev poteka dela s časom poteka, odobriteljem, razlogom in vnosom v revizijski dnevnik.

Uporabite glavno knjigo kot vir resnice

Za nadzor dostopa v realnem času vodite lastno knjigo uporabe. Zunanja orodja za zaračunavanje so odlična za izdajanje računov, vendar običajno niso pravo mesto za sprejemanje odločitev o dovoli ali zavrnitvi na ravni milisekunde.

Dogodek uporabe mora zajeti dovolj podrobnosti za uskladitev računov ponudnika, razlago računov strank in odpravljanje sporov:

{
  "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": "standard obrazložitve",
  "input_tokens": 1850,
  "output_tokens": 420,
  "cached_tokens": 1200,
  "strošek_ponudnika": 0,0142,
  "prodajna_cena": 0,0230,
  "currency": "USD",
  "časovni žig": "2026-08-02T10:15:30Z",
  "status": "uspelo"
}

Zabeležite tudi neuspele zahteve, vendar ločite neuspehe, ki so plačljivi, od neuspešnih. Časovne omejitve ponudnika, napake pri preverjanju, odpovedi strank, ponovni poskusi in varnostne blokade imajo lahko različne obračunske rezultate, odvisno od tega, kdaj se zgodijo.

Priporočilo: napišite čakajoči dogodek glavne knjige, ko je zahteva sprejeta, nato pa ga dokončajte, ko sta znana uporaba žetona in stroški. To vam omogoča, da rezervirate proračun pred usmerjanjem in nato popravite končni znesek po zaključku.

Vzorec usklajevanja

1. Shranjevanje dogodkov na ravni zahteve v notranji knjigi.
2. Skupna poraba glede na stranko, model in obračunsko obdobje.
3. Primerjajte interne vsote z računi navzgornjega ponudnika ali izvozi uporabe.
4. Preučite bistvene razlike pred izdajo računov.
5. Sinhronizirajte povzetek plačljive porabe z obračunskim sistemom.

Kompromis: sinhronizacija povzetka uporabe zmanjša obseg in zapletenost obračunskih dogodkov, vendar lahko račune strank naredi manj podrobne. Če stranke potrebujejo poročanje na ravni modela ali projekta, ohranite te razsežnosti v sinhronizaciji obračunavanja ali na nadzorni plošči stranke.

Sinhronizacija obračunavanja s števci na podlagi uporabe

Sistemi obračunavanja na podlagi uporabe na splošno sledijo vzorcu: definirajo izdelke in cene, vnašajo dogodke uporabe, jih združujejo v obračunskem obdobju, ustvarjajo račune in spremljajo napake. Stripe Billing na primer podpira dogodke števca z imenom dogodka, identifikatorjem stranke, številčno vrednostjo, izbirnim časovnim žigom, izbirnim identifikatorjem idempotence in izbirnimi dimenzijami.

Za obračunavanje API-ja AI so običajne izbire števcev:

• Skupaj žetonov: uporabno, ko je cena tesno povezana z vhodnimi in izhodnimi žetoni.
• Število zahtev: uporabno za preproste načrte ali klice API-ja z malo žetonov.
• Enote, specifične za model: uporabne, kadar imajo premium modeli različne marže.
• Sedeži ali aktivni delovni prostori: uporabno za hibridne načrte uporabe SaaS-plus.

Dejstvo: črtasti merilniki podpirajo formule združevanja, kot so vsota, štetje in zadnja. Ti se preslikajo v skupne vrednosti žetonov, število zahtev in vrednosti, podobne stanju, kot so sedeži ali aktivne omejitve.

Dnevna sinhronizacija obračunavanja lahko ustvari takšne dogodke števca:

{
  "event_name": "ai_tokens_used",
  "stranka": "stripe_customer_456",
  "vrednost": 2270000,
  "časovni žig": "2026-08-02T23:59:00Z",
  "idempotency_key": "cust_acme_2026-08-02_tokens",
  "dimensions": {
    "načrt": "api_za_rast",
    "model_family": "standard"
  }
}

Priporočilo: notranja knjiga naj bo bolj razdrobljena kot račun. Dnevne skupne zneske žetonov lahko fakturirate, medtem ko še vedno hranite zapise na ravni zahtev za podporo, pregled goljufij, prilagoditev omejitve stopnje in analizo marže.

Telegram deluje, ne da bi Telegram postal zapisniški sistem

Telegram je uporaben za hitre poteke dela operaterja: ekipe za podporo že opazijo sporočila, roboti lahko pošiljajo opozorila, stranke pa lahko prejmejo navodila za vkrcanje, ne da bi se prijavile na nadzorno ploščo. Toda Telegram ne bi smel biti edina revizijska sled za odločitve o zaračunavanju, varnosti ali podpori.

Dobri poteki dela Telegrama vključujejo:

• Opozorila o nizkem stanju ali visoki porabi pri 50 %, 80 % in 95 % zgornje meje.
• Sporočila o vključitvi novih strank s povezavami do dokumentacije in prikritimi imeni ključev.
• Obvestila o rotaciji ključa API pred in po rotaciji.
• Izpad ponudnika ali opozorila o poslabšanem modelu.
• Stopnja človeške podpore, ko stranka naleti na ponavljajoče se napake 401, 402, 403 ali 429.

Dejstvo: Klici API-ja Telegram Bot se izvedejo prek HTTPS do končnih točk z žetonom botov, spletni kljuki Telegram pa lahko vključujejo skrivno glavo žetona za pomoč pri preverjanju izvora webhooka.

Priporočilo: shranite ID-je klepeta Telegram kot metapodatke najemnika, vendar jih ne razkrivajte strankam. Zabeležite vsako administrativno dejanje, ki ga sproži bot, v dnevnik notranje revizije z akterjem, časovnim žigom, stranko, staro vrednostjo, novo vrednostjo in razlogom.

Kontrolni seznam za varnost in izolacijo

Preden prodate dostop, preizkusite izolacijo najemnika, kot da stranka aktivno poskuša prestopiti meje.

• Stranka A si ne more ogledati ključev API stranke B.
• Stranka A si ne more ogledati uporabe stranke B, računov, omejitev, ID-jev za klepet Telegram ali stanja zaračunavanja.
• Preklican ključ takoj ne uspe na vseh poteh zahtev.
• Stranka z začasno zaustavitvijo obračunavanja ne more nadaljevati s porabo prek predpomnjenih sej ali starih ključev.
• Stranka ne more zahtevati modelov zunaj dodeljenega načrta.
• Omejitve tarif veljajo glede na stranko in delovni prostor, ne le glede na globalni naslov IP.
• Rukovalniki spletnih trkov preverjajo podpise ali skrivne glave, kjer so podprti.
• Vse zagotavljanje, spremembe omejitev, rotacije ključev in preglasitve zaračunavanja ustvarjajo vnose v revizijski dnevnik.
• Logika ponovnega poskusa uporablja ključe idempotence, tako da podvojene zahteve strankam ne zaračunajo dvojno.
• Orodja za podporo prikrivajo skrivnosti in omejujejo, kdo lahko razkrije ali vrti ključe.

Napoved: portali preprodajalcev bodo vse bolj tekmovali glede upravljanja in jasnosti obračunavanja, ne le glede dostopa do številnih modelov. Stranke bodo kot standardne funkcije pričakovale uporabo za posamezen projekt, jasne račune, hitro rotacijo ključev in nadzor trde porabe.

Ključni kompromisi, o katerih se morate odločiti zgodaj

Predplačilo v primerjavi z naročnino

Predplačniška stanja zmanjšajo kreditno tveganje in poenostavijo trde izločitve, vendar stranke morda ne marajo prekinitev. Naknadno obračunavanje je bolj gladko za uveljavljene stranke, vendar zahteva preverjanje kreditne sposobnosti, opominjanje potekov dela in močnejše zaznavanje nepravilnosti.

Ena kombinirana cena v primerjavi s ceno, specifično za model

Mešano ceno je lažje razložiti. Cene glede na model ščitijo marže in spodbujajo učinkovito izbiro modela. Če ponujate veliko modelov, objavite preprost katalog modelov, namenjen strankam, in skrijte nepotrebno zapletenost, specifično za ponudnika.

Merjenje v realnem času v primerjavi z odloženim obračunavanjem

Merjenje v realnem času omogoča omejitve porabe in predplačniška stanja. Zahteva tudi trajno pisanje, upravljanje ponovnega predvajanja in usklajevanje. Zakasnjeno obračunavanje je enostavnejše, vendar vas izpostavi nenavadni porabi, preden začnejo veljati omejitve.

Podpora za Telegram v primerjavi s podporo za nadzorno ploščo

Telegram je hiter in znan mnogim operaterjem. Nadzorna plošča je boljša za revizijo, izvoze, dovoljenja in samopostrežne storitve za stranke. Uporabite Telegram za obvestila in odobritve, vendar shranite kanonični zapis v svojem sistemu.

Izvedljiv načrt uvedbe

1. Začnite z izolacijo najemnika: implementirajte zapise o strankah, delovnem prostoru, ključih, načrtih in omejitvah, preden dodate napredne funkcije obračunavanja.
2. Izdelajte uveljavljanje pred tiskom: blokirajte preklicane ključe, začasno začasno zaračunavanje, nedovoljene modele in prekoračite omejitev prometa pred usmerjanjem.
3. Ustvarite knjigo uporabe: beležite ID-je zahtev, število žetonov, stroške, cene preprodajalcev, stanja, časovne žige in ključe idempotence.
4. Dodajte uskladitev: primerjajte notranjo porabo s skupnimi zneski ponudnika navzgor, preden izdate račun.
5. Sinhronizirajte povzetke zaračunavanja: pošljite dnevne ali urne agregate na svojo platformo za obračunavanje s stabilnimi preslikavami strank in ključi idempotence.
6. Opozorila Wire Telegram: začnite s sporočili o nizkem stanju, izpadu, rotaciji ključev in eskalaciji podpore.
7. Izvedite izolacijske preizkuse: preverite, ali nobena stranka ne more dostopati do ključev, uporabe, omejitev, računov ali metapodatkov klepeta druge stranke.

Portal za preprodajalce ni le ovoj okoli API-ja AI. Je delovna plast za preverjanje pristnosti, politiko najemnikov, analitiko uporabe, zaračunavanje in podporo. Najprej zgradite glavno knjigo in omejitve, obdržite ključe navzgor na strani strežnika in omogočite, da bo vsak ključ, ki ga vidi stranka, preklican, obsegan in pripisan.

Sorodno branje

• Prakse izolacije in rotacije ključev API
• Tehnike nadzora stroškov API-ja AI
• zavedanje napak usmerjanje in ponovni poskusi