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

Če paketirate dostop AI za odjemalce, 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 zaračunljive vsote z vašim sistemom za zaračunavanje.

Ta vodnik opisuje praktični model delovanja za AI API 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 partnerja API, notranji prehod ali proxy po meri pred več ponudniki modelov.

Arhitektura portala preprodajalcev

Varni portal za preprodajalce ločuje štiri odgovornosti:

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

Tipičen tok izgleda takole:

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

Dejstvo: OpenAI priporoča, da za sodelovanje ne delite ključev, ki temeljijo na uporabniku API, temveč namesto tega uporabite ključe, ki temeljijo na projektu, dodeljene člane in ločene ključe z izoliranimi omejitvami stopnje in nadzorom porabe. Pogoji storitve OpenAI prav tako 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 jasno navesti izolacijo. Shranite vsaj ta polja:

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

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": "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"
}

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: uradno ime trgovine, 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 API ključe: izdajte ključe v obsegu za strankina okolja.
6. Pošljite navodila za integracijo: zagotovite osnovni URL, obliko preverjanja pristnosti, seznam modelov, omejitve in podporni kanal.
7. Omogoči opozorila: poveži Telegram ali drug operativni kanal za obvestila o nizkem stanju, ključu, izpadu in obračunu.
8. Izvedite preizkusno zahtevo: preverite avtentikacijo, beleženje uporabe, dostop do modela in preslikavo računov.

Priporočilo: naj bo vkrcanje idempotentno. Če vaša skrbniška aplikacija znova poskusi operacijo »ustvari stranko«, ne bi smela ustvariti podvojenih zapisov zaračunavanja 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 odkriti, 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.
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 omejitev visoke 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. Ocena najvišjega možnega stroška iz modela, največjega števila žetonov in parametrov zahteve.
9. Usmeri zahtevo le, če je pravilnik sprejet.

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()

Dejstvo: OWASP API Varnost Top 10 2023 omenja pokvarjeno avtorizacijo objektov, pokvarjeno preverjanje pristnosti in neomejeno porabo virov kot glavna API tveganja. 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.

Uporaba knjige kot vira 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": "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"
}

Zabeležite tudi neuspešne 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. Razišč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 na ravni projekta, ohranite te razsežnosti v sinhronizaciji obračunavanja ali na nadzorni plošči stranke.

Sinhronizacija obračunavanja z števci na podlagi uporabe

Sistemi obračunavanja na podlagi uporabe na splošno sledijo vzorcu: definirajo izdelke in cene, vnesejo dogodke uporabe, jih združijo v obračunskem obdobju, ustvarijo 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 zaračunavanje AI API so običajne izbire števcev:

• Skupaj žetonov: uporabno, kadar je oblikovanje cen tesno povezano z vhodnimi in izhodnimi žetoni.
• Število zahtev: uporabno za preproste načrte ali API klice z nizkimi žetoni.
• 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 zadnji. 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 dogodke števca, kot je ta:

{
  "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"
  }
}

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

Telegram operacije brez ustvarjanja Telegram sistema zapisov

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

Dobri Telegram poteki dela 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.
• API-obvestila o rotaciji tipk pred in po rotaciji.
• Opozorila o izpadu ponudnika ali degradiranem modelu.
• Eskalacija človeške podpore, ko stranka naleti na ponavljajoče se napake 401, 402, 403 ali 429.

Dejstvo: Telegram Klici bota API se izvedejo prek HTTPS do končnih točk bot-žetona in Telegram webhooki lahko vključujejo skrivno glavo žetona za pomoč pri preverjanju izvora webhooka.

Priporočilo: shranite Telegram ID-je klepeta 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, Telegram ID-jev klepeta ali stanja obrač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 Webhook preverjajo podpise ali tajne 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.
• Podporna orodja prikrivajo skrivnosti in omejujejo, kdo lahko razkrije ali vrti ključe.

Napoved: portali preprodajalcev bodo vedno 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 zgodaj odločiti

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, ki je specifična 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.

Telegram-prva podpora v primerjavi z nadzorno ploščo-prva podpora

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 vašem sistemu.

Izvedljiv načrt uvedbe

1. Začnite z izolacijo najemnika: implementirajte zapise strank, delovnih prostorov, ključev, načrtov in omejitev, preden dodate napredne funkcije zarač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: zabeleži 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 pred izdajanjem računov.
5. Sinhronizacija povzetkov zaračunavanja: pošiljanje dnevnih ali urnih agregatov na vašo platformo za obračunavanje s stabilnimi preslikavami strank in ključi idempotence.
6. Opozorila Telegram o žični povezavi: se začnejo 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 samo ovoj okrog AI API. Je delovna plast za preverjanje pristnosti, politiko najemnikov, analitiko uporabe, zaračunavanje in podporo. Najprej zgradite glavno knjigo in omejitve, obdržite navzgornje ključe na strani strežnika in poskrbite, da bo vsak ključ, usmerjen v stranko, preklicljiv, obsegan in pripisan.

Sorodno branje

• API prakse izolacije in rotacije ključev
• AI API nadzor stroškov tehnike
• usmerjanje ob upoštevanju napak in ponovni poskusi