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

Ako pakirate AI pristup za klijente, nemojte im predavati svoje ključeve pružatelja uzlaznih 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 partnera 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 stvaranje kupaca, planova, ključeva, ograničenja i tijeka rada podrške.
• Provedba zahtjeva: put pristupnika koji provjerava autentičnost korisničkih ključeva, provjerava pravila, usmjerava zahtjeve i blokira promet preko ograničenja.
• Obračun upotrebe: izdržljiva knjiga koja bilježi upotrebu na razini zahtjeva i unose cijena.
• Naplata i operacije: zakazana sinkronizacija faktura, upozorenja, obavijesti o rotaciji ključeva i eskalacija podrške.

Tipični tok izgleda ovako:

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

Činjenica: OpenAI preporučuje da se ne dijele ključevi temeljeni na korisniku API za suradnju i da se umjesto toga koriste ključevi temeljeni na projektu, dodijeljeni članovi i različiti 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ćim stranama ili od njih. Te činjenice podupiru dizajn preprodavača gdje uzlazne vjerodajnice ostaju na strani poslužitelja, a korisnici primaju vaše vlastite nizvodne ključeve.

Preporuka: izdajte jedan nizvodni ključ po klijentu, 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 stanara trebao bi jasno navesti izolaciju. Najmanje pohranite ova 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ćem portalu dodajte polja za pretplaćeni saldo, valutu, poreznu regiju, ID korisnika fakture, razinu podrške, status zlouporabe i privremena nadjačavanja.

Primjer evidencije korisnika

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

Preporuka: customer_id, workspace_id i api_key_id tretirajte kao zasebne koncepte. Kupac može imati više radnih prostora, a svaki radni prostor može trebati zasebne ključeve za proizvodnju, postavljanje i razvoj. To čini opoziv, otklanjanje pogrešaka i pripisivanje korištenja puno lakšim.

Slijed uključivanja za novog korisnika

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

1. Stvorite kupca: službeno ime trgovine, 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, označavanje, ritam naplate i očekivanja podrške.
4. Postavite ograničenja: konfigurirajte ograničenja potrošnje, ograničenja zahtjeva, ograničenja tokena i burst pravilo.
5. Stvorite API ključeve: izdajte ključeve s opsegom 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 probni 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 uzlaznog modela. Vaš pristupnik ne bi trebao otkriti da korisnik premašuje proračun tek nakon što vam je pružatelj usluga već naplatio.

Koristite ovaj redoslijed prije leta:

1. Provjerite autentičnost nizvodnog API ključa.
2. Riješ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, prekoračeno 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 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()

Činjenica: OWASP API Top 10 sigurnosnih 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 usluga.

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

Korištenje 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": "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"
}

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 je zahtjev 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. Pohrani događaje na razini zahtjeva u internu knjigu.
2. Ukupna upotreba prema korisniku, modelu i razdoblju naplate.
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 fakture korisnika učiniti manje detaljnim. Ako korisnici trebaju izvješćivanje na razini modela ili projekta, sačuvajte te dimenzije u sinkronizaciji naplate ili na 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, zbrajaju ih tijekom razdoblja naplate, generiraju fakture i prate pogreške. Stripe Billing, na primjer, podržava događaje brojila s nazivom događaja, identifikatorom korisnika, numeričkom vrijednošću, izbornom vremenskom oznakom, izbornim identifikatorom idempotencije i izbornim dimenzijama.

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

• Ukupni token: korisno kada je cijena usko povezana s ulaznim i izlaznim tokenima.
• Broj zahtjeva: korisno za jednostavne planove ili API pozive s malo tokena.
• Jedinice specifične za model: korisne kada premium modeli imaju različite marže.
• Sjedala ili aktivni radni prostori: korisni za hibridne SaaS-plus planove upotrebe.

Činjenica: Stripe mjerači podržavaju formule zbrajanja kao što su zbroj, broj 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",
  "value": 2270000,
  "timestamp": "2026-08-02T23:59:00Z",
  "idempotency_key": "cust_acme_2026-08-02_tokens",
  "dimensions": {
    "plan": "growth_api",
    "model_family": "standard"
  }
}

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

Telegram operacije bez pravljenja Telegram sustava zapisa

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. No Telegram ne bi trebao biti jedini revizijski trag za odluke o naplati, sigurnosti ili podršci.

Dobri Telegram tijekovi rada 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.
• API-obavijesti o rotaciji tipki 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 se upućuju preko HTTPS do krajnjih točaka bot-tokena, a Telegram web-dojavnici mogu uključivati tajno zaglavlje tokena za pomoć pri provjeri porijekla web-dojavnika.

Preporuka: pohranite Telegram ID-ove 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, korisnikom, starom vrijednošću, novom vrijednošću i razlogom.

Kontrolni popis za sigurnost i izolaciju

Prije prodaje pristupa, 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 upotrebu korisnika 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-dojavnikom provjeravaju potpise ili tajna zaglavlja ako su podržani.
• Sva opremanja, promjene 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 odlučiti rano

Prepaid u odnosu na postpaid

Unaprijed plaćeni saldo smanjuje kreditni rizik i čini 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 bolje 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 u odnosu na odgođenu naplatu

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.

Telegram-prva podrška u odnosu na nadzornu ploču-prva podrška

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: zabiljež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. Sinkroniziraj sažetke naplate: pošalji dnevne ili satne agregate na svoju platformu za naplatu sa stabilnim preslikavanjem korisnika i ključevima idempotencije.
6. Upozorenja o žicama Telegram: počinju 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 umjetne inteligencije API. 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č usmjeren prema klijentu može opozvati, odrediti opseg i pripisati.

Povezana literatura

• API prakse izolacije i rotacije ključeva
• AI API kontrola troškova tehnike
• usmjeravanje svjesno greške i ponovni pokušaji