Izgradite portal prodavača AI API-ja: pružanje zakupaca, mjerenje upotrebe, naplata i Telegram operacije

Ako paketirate AI pristup za klijente, nemojte im predavati svoje ključeve uzvodnog pružatelja usluga. Izgradite sloj preprodavača koji izdaje ključeve s opsegom korisnika, provodi ograničenja zakupaca prije svakog zahtjeva, bilježi korištenje u vašoj vlastitoj knjizi i sinkronizira naplative ukupne iznose s vašim sustavom naplate.

Ovaj vodič opisuje praktični operativni model za AI API za agencije, konzultante i graditelje SaaS-a. To nije studija slučaja kupca. To je referentna arhitektura koju možete prilagoditi bilo da koristite partnerski API, interni pristupnik ili prilagođeni proxy pred višestrukim pružateljima modela.

Arhitektura portala prodavača

Siguran portal za prodavače odvaja četiri odgovornosti:

• Administracija partnera: vaša interna aplikacija za kreiranje kupaca, planova, ključeva, ograničenja i radnih tokova podrške.
• Provedba zahtjeva: put pristupnika koji autentificira korisničke ključeve, provjerava pravila, usmjerava zahtjeve i blokira prekoračenje prometa.
• Računovodstvo upotrebe: izdržljiva knjiga koja bilježi upotrebu na razini zahtjeva i unose cijena.
• Naplata i operacije: zakazana sinkronizacija računa, upozorenja, obavijesti o rotaciji ključeva i eskalacija podrške.

Tipični tok izgleda ovako:

Administratorska aplikacija partnera
  → Partner API
    → evidencija kupaca/radnog prostora
    → API ključevi u opsegu korisnika
    → plan, model, proračun i ograničenja stope
    → pristupnik zahtjeva
    → knjiga korištenja
    → sinkronizacija naplate
    → Telegramov bot za obavijesti

Činjenica: OpenAI preporučuje da se ne dijele API ključevi temeljeni na korisniku za suradnju, već da se umjesto toga koriste ključevi temeljeni na projektu, dodijeljeni članovi i posebni ključevi s izoliranim ograničenjima stope i kontrolama potrošnje. Uvjeti usluga OpenAI također zabranjuju kupnju, prodaju ili prijenos API ključeva trećoj strani ili od nje. Te činjenice podupiru dizajn preprodavača gdje uzvodne vjerodajnice ostaju na strani poslužitelja, a korisnici primaju vaše vlastite nizvodne ključeve.

Preporuka: izdajte jedan nizvodni ključ po korisniku, projektu ili okruženju. Nemojte ponovno koristiti jedan korisnički ključ na više krajnjih klijenata. Ne otkrivajte vjerodajnice uzlaznog pružatelja usluga u dokumentaciji, kodu preglednika, mobilnim aplikacijama, zapisima ili porukama podrške klijentima.

Podatkovni model zakupca

Model zakupca trebao bi izolaciju učiniti eksplicitnom. Pohranite najmanje ova polja:

partner_id
customer_id
radni_id
api_key_id
plan_id
status_naplate
limit_trošenja
granica_stope
dozvoljeni_modeli
telegram_chat_id
usage_knjiga_id
created_at
ažurirano_at
revoked_at

Na većem portalu dodajte polja za pretplaćeni saldo, valutu, poreznu regiju, korisnički ID fakture, razinu podrške, status zloupotrebe i privremena nadjačavanja.

Primjer evidencije kupaca

{
  "partner_id": "partner_123",
  "customer_id": "cust_acme",
  "workspace_id": "ws_prod",
  "plan_id": "api_rasta",
  "billing_status": "aktivno",
  "spend_limit": {
    "razdoblje": "mjesec",
    "hard_cap_usd": 500,
    "pragovi_uzbune": [0,5, 0,8, 0,95]
  },
  "ograničenje_stope": {
    "zahtjevi_po_minuti": 120,
    "tokeni_po_danu": 2000000
  },
  "allowed_models": ["fast-chat", "reasoning-standard"],
  "telegram_chat_id": "-1001234567890",
  "usage_ledger_id": "ledger_cust_acme"
}

Preporuka: tretirajte customer_id, workspace_id i api_key_id kao zasebne koncepte. Kupac može imati više radnih prostora, a svaki radni prostor može trebati zasebne proizvodne, prizorne i razvojne ključeve. To znatno olakšava opoziv, otklanjanje pogrešaka i pripisivanje upotrebe.

Slijed uključivanja za novog kupca

Pouzdani tijek integracije dosadan je po svojoj zamisli. Svaki put bi trebao proizvesti iste zapise i ostaviti revizijski trag.

1. Stvorite kupca: pohranite službeno ime, kontakt za naplatu, tehnički kontakt i internog vlasnika.
2. Stvorite radni prostor: odvojite proizvodnju od testiranja ako će korisnik integrirati programski.
3. Dodijelite plan: definirajte uključene modele, oznake, takt naplate i očekivanja podrške.
4. Postavite ograničenja: konfigurirajte ograničenja potrošnje, ograničenja zahtjeva, ograničenja tokena i burst pravila.
5. Stvorite API ključeve: izdajte ograničene ključeve za klijentova okruženja.
6. Pošaljite upute za integraciju: navedite osnovni URL, format provjere autentičnosti, popis modela, ograničenja i kanal podrške.
7. Omogućite upozorenja: povežite Telegram ili neki drugi operativni kanal za obavijesti o niskom stanju, ključu, prekidu rada i naplati.
8. Pokrenite testni zahtjev: provjerite autentifikaciju, bilježenje upotrebe, pristup modelu i mapiranje faktura.

Preporuka: uključivanje učinite idempotentnim. Ako vaša aplikacija administratora ponovno pokuša operaciju "stvori kupca", ne bi trebala stvoriti duple zapise o naplati ili duple API ključeve. Koristite vanjske ID-ove i ključeve idempotencije za pružanje poziva.

Kontrola proračuna za vrijeme zahtjeva

Najvažnija provedba događa se prije nego što zahtjev stigne do uzvodnog modela. Vaš pristupnik ne bi trebao otkriti da korisnik premašuje budžet tek nakon što vam je pružatelj usluge već naplatio.

Koristite ovaj redoslijed prije leta:

1. Provjerite autentičnost nizvodnog API ključa.
2. Razriješi partner_id, customer_id i workspace_id.
3. Provjerite je li ključ aktivan i nije opozvan.
4. Provjerite status naplate: aktivno, probno, unaprijed plaćeno, pauzirano, kasni ili obustavljeno.
5. Provjerite gornju granicu potrošnje za trenutno obračunsko razdoblje.
6. Provjerite ograničenja stope, kao što su zahtjevi po minuti i tokeni po danu.
7. Provjerite je li traženi model dopušten za kupčev plan.
8. Procijenite najveći mogući trošak na temelju modela, maksimalnih tokena i parametara zahtjeva.
9. Usmjerite zahtjev samo ako pravilo prođe.

if key.revoked:
    reject(401, "API ključ opozvan")
if customer.billing_status u ["paused", "suspended", "overdue"]:
    reject(402, "Status naplate ne dopušta korištenje")
if requested_model nije u customer.allowed_models:
    reject(403, "Model nije omogućen za ovaj radni prostor")
if current_period_spend + procijenjeni_max_cost > customer.hard_cap:
    reject(402, "Ograničenje potrošnje premašeno")
if rate_limit_exceeded(customer_id, requested_model):
    odbaci(429, "Ograničenje brzine premašeno")
route_request()

Činjenica: Top 10 sigurnosti OWASP API-ja za 2023. kao glavne API rizike navodi neispravnu autorizaciju objekta, neispravnu autentifikaciju i neograničenu potrošnju resursa. Oni se preslikavaju izravno na portale preprodavača: jedan zakupac ne smije čitati podatke drugog zakupca, ključevi se ne smiju zaobići, a jedan korisnik ne smije moći stvoriti neograničenu potrošnju davatelja.

Kompromis: stroga ograničenja štite vašu maržu, ali mogu prekinuti legitimne skokove. Dobar kompromis je privremeni nadjačavajući radni tijek s vremenom isteka, odobravateljem, razlogom i unosom u dnevnik revizije.

Korištenje glavne knjige kao izvora istine

Za kontrolu pristupa u stvarnom vremenu vodite vlastitu knjigu korištenja. Eksterni alati za naplatu izvrsni su za fakturiranje, ali obično nisu pravo mjesto za donošenje odluka o dopuštanju ili odbijanju na razini milisekunde.

Događaj korištenja trebao bi obuhvatiti dovoljno detalja za usklađivanje faktura davatelja usluga, objašnjenje korisničkih računa i otklanjanje sporova:

{
  "request_id": "req_01J...",
  "idempotency_key": "idem_abc123",
  "partner_id": "partner_123",
  "customer_id": "cust_acme",
  "workspace_id": "ws_prod",
  "api_key_id": "ključ_live_789",
  "model": "standard obrazloženja",
  "input_tokens": 1850,
  "output_tokens": 420,
  "cached_tokens": 1200,
  "provider_cost": 0,0142,
  "cijena_prodavača": 0,0230,
  "currency": "USD",
  "vremenska oznaka": "2026-08-02T10:15:30Z",
  "status": "uspjelo"
}

Zabilježite i neuspjele zahtjeve, ali razlikujete neuspjele koji se naplaćuju od neuspjelih. Isteci vremena pružatelja, neuspjele provjere valjanosti, otkazivanja korisnika, ponovni pokušaji i sigurnosne blokade mogu imati različite računovodstvene ishode ovisno o tome kada se dogode.

Preporuka: napišite događaj glavne knjige na čekanju kada zahtjev bude prihvaćen, a zatim ga finalizirajte kada upotreba tokena i cijena budu poznati. To vam omogućuje da rezervirate proračun prije usmjeravanja i zatim ispravite konačni iznos nakon završetka.

Uzorak usklađivanja

1. Pohranjujte događaje na razini zahtjeva u internu knjigu.
2. Ukupna upotreba prema kupcu, modelu i obračunskom razdoblju.
3. Usporedite interne ukupne iznose s fakturama uzvodnog pružatelja usluga ili izvozima korištenja.
4. Istražite materijalne razlike prije izdavanja faktura.
5. Sinkronizirajte sažetak naplative upotrebe sa sustavom naplate.

Kompromis: sinkronizacija sažete upotrebe smanjuje količinu i složenost događaja naplate, ali može učiniti račune korisnika manje detaljnim. Ako korisnici trebaju izvješćivanje na razini modela ili projekta, sačuvajte te dimenzije u sinkronizaciji naplate ili nadzornoj ploči korisnika.

Sinkronizacija naplate s mjeračima koji se temelje na upotrebi

Sustavi naplate temeljeni na korištenju općenito slijede obrazac: definiraju proizvode i cijene, unose događaje korištenja, agregiraju ih tijekom obračunskog razdoblja, generiraju fakture i nadziru pogreške. Stripe Billing, na primjer, podržava događaje brojila s nazivom događaja, identifikatorom kupca, numeričkom vrijednošću, izbornom vremenskom oznakom, izbornim identifikatorom idempotencije i izbornim dimenzijama.

Za naplatu AI API-ja, uobičajeni izbori brojila su:

• Ukupni token: korisno kada je cijena usko povezana s ulaznim i izlaznim žetonima.
• Broj zahtjeva: korisno za jednostavne planove ili API pozive s malim tokenom.
• Jedinice specifične za model: korisne kada vrhunski modeli imaju različite marže.
• Sjedala ili aktivni radni prostori: korisni za hibridne SaaS-plus planove korištenja.

Činjenica: Stripe mjerači podržavaju formule zbrajanja kao što su zbroj, brojač i zadnji. Oni se preslikavaju na ukupne tokene, brojeve zahtjeva i vrijednosti nalik stanju kao što su mjesta ili aktivna ograničenja.

Dnevna sinkronizacija naplate može stvoriti događaje brojila poput ovog:

{
  "event_name": "ai_tokens_used",
  "customer": "stripe_customer_456",
  "vrijednost": 2270000,
  "vremenska oznaka": "2026-08-02T23:59:00Z",
  "idempotency_key": "cust_acme_2026-08-02_tokens",
  "dimenzije": {
    "plan": "api_rasta",
    "model_family": "standard"
  }
}

Preporuka: neka interna knjiga bude detaljnija od fakture. Možete fakturirati dnevne ukupne tokene dok i dalje zadržavate zapise na razini zahtjeva za podršku, pregled prijevara, podešavanje ograničenja stope i analizu margine.

Operacije Telegrama bez postavljanja Telegrama kao sustava evidencije

Telegram je koristan za brze tijekove rada operatera: timovi za podršku već primjećuju poruke, botovi mogu slati upozorenja, a korisnici mogu primati upute za uključivanje bez prijave na nadzornu ploču. Ali Telegram ne bi trebao biti jedini revizijski trag za odluke o naplati, sigurnosti ili podršci.

Dobri tijekovi rada Telegrama uključuju:

• Upozorenja o niskom saldu ili visokoj potrošnji na 50%, 80% i 95% ograničenja.
• Poruke o uključivanju novih kupaca s vezama na dokumentaciju i maskiranim imenima ključeva.
• Obavijesti o rotaciji API-ključa prije i poslije rotacije.
• Upozorenja o ispadu pružatelja usluga ili degradiranom modelu.
• Eskalacija ljudske podrške kada korisnik naiđe na ponovljene pogreške 401, 402, 403 ili 429.

Činjenica: Telegram Bot API pozivi upućuju se preko HTTPS-a do krajnjih točaka bot-tokena, a web-dojavnici Telegrama mogu sadržavati zaglavlje tajnog tokena za pomoć pri provjeri porijekla web-dojavnika.

Preporuka: pohranite ID-ove Telegram chata kao metapodatke stanara, ali ih nemojte izlagati korisnicima. Zabilježite svaku administrativnu radnju koju je pokrenuo bot u svoj dnevnik interne revizije s akterom, vremenskom oznakom, klijentom, starom vrijednošću, novom vrijednošću i razlogom.

Popis za provjeru sigurnosti i izolacije

Prije nego što prodate pristup, testirajte izolaciju stanara kao da kupac aktivno pokušava prijeći granice.

• Klijent A ne može vidjeti API ključeve kupca B.
• Klijent A ne može vidjeti korištenje klijenta B, fakture, ograničenja, Telegram ID-ove chata ili status naplate.
• Opozvani ključ odmah ne uspijeva na svim stazama zahtjeva.
• Klijent s pauziranom naplatom ne može nastaviti trošiti kroz predmemorirane sesije ili stare ključeve.
• Kupac ne može zahtijevati modele izvan dodijeljenog plana.
• Ograničenja stope primjenjuju se prema korisniku i radnom prostoru, a ne samo prema globalnoj IP adresi.
• Rukovatelji web-dojavnika provjeravaju potpise ili tajna zaglavlja ako su podržani.
• Sva dodjela, izmjene ograničenja, rotacije ključeva i nadjačavanja naplate stvaraju unose revizijskog dnevnika.
• Logika ponovnog pokušaja koristi ključeve idempotencije kako dvostruki zahtjevi ne bi dvostruko naplatili klijente.
• Alati za podršku maskiraju tajne i ograničavaju tko može otkriti ili rotirati ključeve.

Predviđanje: portali prodavača će se sve više natjecati u upravljanju i jasnoći naplate, ne samo u pristupu mnogim modelima. Kupci će kao standardne značajke očekivati korištenje po projektu, jasne fakture, brzu rotaciju ključeva i kontrolu potrošnje.

Ključni kompromisi o kojima treba rano odlučiti

Prepaid u odnosu na postpaid

Unaprijed plaćeni saldi smanjuju kreditni rizik i čine teška ograničenja jednostavnima, no klijentima se možda neće svidjeti prekidi. Postpaid naplata lakša je za etablirane korisnike, ali zahtijeva kreditne provjere, tijekove rada s opomenama i snažnije otkrivanje anomalija.

Jedna kombinirana cijena u odnosu na cijene specifične za model

Mješovitu cijenu lakše je objasniti. Cijene specifične za model štite marže i potiču učinkovit odabir modela. Ako nudite mnogo modela, objavite jednostavan katalog modela usmjeren na korisnike i sakrijte nepotrebnu složenost specifičnu za pružatelja usluga.

Mjerenje u stvarnom vremenu naspram odgođene naplate

Mjerenje u stvarnom vremenu omogućuje ograničenje potrošnje i unaprijed plaćena stanja. Također zahtijeva dugotrajno pisanje, rukovanje ponavljanjem i usklađivanje. Odgođena naplata je jednostavnija, ali vas izlaže nenamjernoj potrošnji prije nego što ograničenja stupe na snagu.

Podrška na prvom mjestu za Telegram naspram podrške na prvom mjestu nadzorne ploče

Telegram je brz i poznat mnogim operaterima. Nadzorna ploča je bolja za reviziju, izvoze, dozvole i samoposluživanje korisnika. Koristite Telegram za obavijesti i odobrenja, ali pohranite kanonski zapis u svoj sustav.

Izvediv plan uvođenja

1. Počnite s izolacijom zakupca: implementirajte evidenciju korisnika, radnog prostora, ključa, plana i ograničenja prije dodavanja naprednih značajki naplate.
2. Izgradite provedbu prije provjere: blokirajte opozvane ključeve, obustavljenu naplatu, nedopuštene modele i prekoračite promet prije usmjeravanja.
3. Stvorite knjigu korištenja: bilježite ID-ove zahtjeva, brojeve tokena, troškove, cijene preprodavača, statuse, vremenske oznake i ključeve idempotencije.
4. Dodajte usklađivanje: usporedite internu upotrebu s ukupnim iznosima dobavljača prije fakturiranja.
5. Sinkronizacija sažetaka naplate: pošaljite dnevne ili satne agregate na svoju platformu za naplatu sa stabilnim preslikavanjem korisnika i ključevima idempotencije.
6. Upozorenja za Wire Telegram: počnite s porukama o niskom stanju, prekidu rada, rotaciji ključeva i eskalaciji podrške.
7. Pokrenite izolacijske testove: potvrdite da nijedan korisnik ne može pristupiti ključevima, korištenju, ograničenjima, fakturama ili metapodacima chata drugog korisnika.

Portal prodavača nije samo omotač oko AI API-ja. To je operativni sloj za autentifikaciju, politiku zakupca, analitiku korištenja, naplatu i podršku. Najprije izgradite glavnu knjigu i ograničenja, držite uzlazne ključeve na strani poslužitelja i učinite da se svaki ključ prema korisniku može opozvati, dodijeliti i pripisati.

Povezano čitanje

• Prakse izolacije i rotacije ključeva API-ja
• Tehnike kontrole troškova AI API-ja
• svjesni kvara usmjeravanje i ponovni pokušaji