Looge AI API edasimüüjate portaal: rentnike varustamine, kasutuse mõõtmine, arveldamine ja telegrammi toimingud
Praktiline tugiarhitektuur agentuuridele, konsultantidele ja SaaS-i ehitajatele, mis pakub klientidele AI API-juurdepääsu: rentnike kirjed, kliendi ulatusega võtmed, kululimiidid, kasutusreskontrad, arvelduste sünkroonimine ja Telegrami toimingud.
Kui pakute klientidele AI-juurdepääsu, ärge andke neile üle oma teenusepakkuja võtmeid. Looge edasimüüjakiht, mis väljastab kliendi ulatusega võtmeid, jõustab rentnike piirangud enne iga päringut, registreerib kasutuse oma pearaamatusse ja sünkroonib arveldatavad kogusummad teie arveldussüsteemiga.
See juhend kirjeldab AI API praktilist töömudelit agentuuridele, konsultantidele ja SaaS-i koostajatele. Tegemist ei ole kliendi juhtumiuuringuga. See on võrdlusarhitektuur, mida saate kohandada olenemata sellest, kas kasutate partneri API-t, sisemist lüüsi või kohandatud puhverserverit mitme mudeli pakkuja ees.
Edasimüüjaportaali arhitektuur
Turvaline edasimüüjaportaal jagab nelja vastutusala:
- Partneri haldus: teie sisemine rakendus klientide, plaanide, võtmete, piirangute ja tugitöövoogude loomiseks.
- Taotluse jõustamine: lüüsi tee, mis autentib kliendi võtmeid, kontrollib eeskirju, suunab päringuid ja blokeerib ülepiiranguga liiklust.
- Kasutusarvestus: vastupidav pearaamat, mis salvestab taotluse tasemel kasutus- ja hinnasisendeid.
- Arveldamine ja toimingud: ajastatud arvete sünkroonimine, märguanded, võtmete vaheldumise teatised ja toe eskalatsioon.
Tüüpiline voog näeb välja selline:
Partneri administraatori rakendus
→ Partner API
→ kliendi / tööruumi kirjed
→ kliendi ulatusega API võtmed
→ plaan, mudel, eelarve ja intressipiirangud
→ päringu lüüs
→ kasutusraamat
→ arvelduse sünkroonimine
→ Telegrami teavitusbotFakt: OpenAI soovitab mitte jagada koostööks kasutajapõhiseid API-võtmeid ning selle asemel kasutada projektipõhiseid võtmeid, määratud liikmeid ja eraldi võtmeid, millel on eraldatud määralimiidid ja kulukontrollid. OpenAI teenuste tingimused keelavad ka API võtmete ostmise, müümise või kolmandale osapoolele ülekandmise. Need faktid toetavad edasimüüja kujundust, kus ülesvoolu mandaadid jäävad serveri pooleks ja kliendid saavad teie enda allavoolu võtmed.
Soovitus: väljasta üks allavoolu võti kliendi, projekti või keskkonna kohta. Ärge taaskasutage ühte kliendivõtit mitme lõppkliendi vahel. Ärge avaldage ülesvoolu pakkuja mandaate dokumentides, brauseri koodis, mobiilirakendustes, logides ega klienditoe sõnumites.
Üürniku andmemudel
Üürnikumudel peaks eraldama selgesõnaliselt. Salvestage vähemalt järgmised väljad:
partneri_id kliendi_id tööruumi_id api_key_id plaani_id arvelduse_olek kulu_limiit rate_limit lubatud_mudelid telegrammi_vestluse_id usage_redger_id loodud_at uuendatud_at tühistatud_at
Suuremas portaalis lisage väljad ettemaksusaldo, valuuta, maksupiirkonna, arve kliendi ID, tugitaseme, väärkasutuse oleku ja ajutiste alistamiste jaoks.
Kliendikirje näidis
Soovitus: käsitlege customer_id, workspace_id ja api_key_id eraldi mõistetena. Kliendil võib olla mitu tööruumi ja iga tööruum võib vajada eraldi tootmis-, lavastus- ja arendusvõtmeid. See muudab tühistamise, silumise ja kasutamise omistamise palju lihtsamaks.
Uue kliendi liitumise järjekord
Usaldusväärne liitumisvoog on disainilt igav. See peaks tootma iga kord samu kirjeid ja jätma kontrolljälje.
- Looge klient: salvestage juriidiline nimi, arvelduskontakt, tehniline kontakt ja sisemine omanik.
- Tööruumi loomine: eraldage tootmine testimisest, kui klient integreerib programmiliselt.
- Määrake plaan: määrake kaasatud mudelid, märgistus, arveldussagedus ja toe ootused.
- Limiitide määramine: konfigureerige kululimiite, taotluspiiranguid, märgipiiranguid ja sarivõtte eeskirju.
- API-võtmete loomine: andke välja kliendi keskkondade jaoks ulatusega võtmed.
- Integreerimisjuhiste saatmine: esitage põhi-URL, autentimisvorming, mudeliloend, piirangud ja tugikanal.
- Hoiatuste lubamine: ühendage Telegram või mõni muu toimingute kanal madala saldo, võtme, katkestuste ja arveldusteatiste saamiseks.
- Käitage testpäring: kontrollige autentimist, kasutuse salvestamist, mudelile juurdepääsu ja arvete vastendamist.
Soovitus: muutke liitumine idempotentseks. Kui teie administraatorirakendus proovib uuesti kliendi loomise toimingut, ei tohiks see luua dubleerivaid arvelduskirjeid ega API-võtmeid. Kasutage kõnede ettevalmistamiseks väliseid ID-sid ja idempotentsusvõtmeid.
Taotluse aja eelarve juhtimine
Kõige olulisem jõustamine toimub enne, kui taotlus jõuab ülesvoolu mudelini. Teie lüüs ei tohiks avastada, et klient ületab eelarve alles pärast seda, kui teenusepakkuja on teilt juba tasu võtnud.
Kasutage seda eelkontrolli jada:
- Autentige allavoolu API võti.
- Lahendage
partner_id,customer_idjaworkspace_id. - Kontrollige, kas võti on aktiivne ja seda ei ole tühistatud.
- Kontrollige arveldusolekut: aktiivne, prooviversioon, ettemakstud, peatatud, tähtaja ületanud või peatatud.
- Vaadake jooksva arveldusperioodi kululimiiti.
- Kontrollige määrpiiranguid, nagu taotlusi minutis ja lubasid päevas.
- Kontrollige, kas taotletud mudel on kliendi plaani jaoks lubatud.
- Prognoosige mudeli, maksimaalsete lubade ja päringu parameetrite järgi maksimaalset võimalikku kulu.
- Muutke taotlus ainult siis, kui eeskirjad läbivad.
kui key.revoked:
reject(401, "API võti tühistatud")
if customer.billing_status in ["peatatud", "peatatud", "hilinenud"]:
reject(402, "Arvelduse olek ei luba kasutamist")
kui requested_model pole kaustas customer.allowed_models:
reject(403, "Mudel pole selle tööruumi jaoks lubatud")
kui praegune_periood_kulu + hinnanguline_maksimaalne_kulu > klient.kõva_kork:
reject(402, "Kululimiit ületatud")
if rate_limit_exceeded(customer_id, requested_model):
reject(429, "Määruse piirang ületatud")
route_request()Fakt: OWASP API turvalisuse 10 parimat 2023. aasta edetabelit nimetab peamiste API riskidena vigastatud objektide autoriseerimist, rikutud autentimist ja piiramatut ressursitarbimist. Need seostuvad otse edasimüüjate portaalidega: üks üürnik ei tohi lugeda teise üürniku andmeid, võtmed ei tohi olla möödapääsetavad ja üks klient ei tohi hankida piiramatuid teenusepakkuja kulutusi.
Muu: ranged piirid kaitsevad teie marginaali, kuid võivad katkestada seaduslikud hüpped. Hea kompromiss on ajutine alistamise töövoog koos aegumisaja, kinnitaja, põhjuse ja auditilogi kirjega.
Kasutage tõe allikana pearaamatut
Reaalajas juurdepääsu juhtimiseks hoidke enda kasutusreskontra. Välised arveldustööriistad sobivad suurepäraselt arveldamiseks, kuid tavaliselt pole need õige koht millisekundi tasemel lubamise või keelamise otsuste tegemiseks.
Kasutussündmus peaks sisaldama piisavalt üksikasju, et võrrelda teenusepakkuja arveid, selgitada klientide arveid ja siluda vaidlusi.
Salvestage ka ebaõnnestunud taotlused, kuid eristage tõrkeid, mille eest tuleb tasuda, ja tõrkeid, mis ei ole arveldatavad. Pakkuja ajalõppudel, valideerimise tõrgetel, klientide tühistamistel, korduskatsetel ja turvablokeeringutel võivad olla erinevad arvestustulemused olenevalt nende ilmnemise ajast.
Soovitus: kirjutage ootel pearaamatu sündmus, kui taotlus võetakse vastu, ja viimistlege see siis, kui loa kasutamine ja maksumus on teada. See võimaldab teil eelarve enne marsruutimist reserveerida ja pärast lõpetamist lõppsummat korrigeerida.
Leppimismuster
- Salvestage päringutaseme sündmused sisemisse pearaamatusse.
- Koondkasutus kliendi, mudeli ja arveldusperioodi lõikes.
- Võrrelge sisemisi kogusummasid ülesvoolu pakkuja arvete või kasutusekspordiga.
- Enne arvete väljastamist uurige olulisi erinevusi.
- Sünkroonige kokkuvõtlik arveldatav kasutus arveldussüsteemiga.
Komppror: kokkuvõtliku kasutuse sünkroonimine vähendab arveldussündmuste mahtu ja keerukust, kuid võib muuta klientide arved vähem üksikasjalikuks. Kui kliendid vajavad mudeli- või projektitaseme aruandlust, säilitage need dimensioonid oma arvelduse sünkroonimisel või kliendi juhtpaneelil.
Arvelduse sünkroonimine kasutuspõhiste arvestitega
Kasutuspõhised arveldussüsteemid järgivad üldiselt mustrit: määratlevad tooted ja hinnad, võtavad kasutusele kasutussündmused, koondavad need arveldusperioodi jooksul, genereerivad arveid ja jälgivad vigu. Stripe Billing toetab näiteks arvestisündmusi sündmuse nime, kliendi identifikaatori, arvväärtuse, valikulise ajatempli, valikulise idempotentsuse identifikaatori ja valikuliste mõõtmetega.
AI API arveldamiseks on levinumad mõõtuvalikud järgmised:
- Tokenide kogusumma: kasulik, kui hinnakujundus on tihedalt seotud sisend- ja väljundmärkidega.
- Taotluste arv: kasulik lihtsate plaanide või madalate API-kutsete jaoks.
- Mudelispetsiifilised ühikud: kasulik, kui esmaklassilistel mudelitel on erinevad veerised.
- Istmed või aktiivsed tööruumid: kasulik hübriidsete SaaS-pluss kasutusplaanide jaoks.
Fakt: triibumõõturid toetavad koondvalemeid, nagu summa, arv ja viimane. Need vastavad lubade kogusummadele, taotluste arvule ja olekulaadsetele väärtustele, nagu istekohad või aktiivsed limiidid.
Igapäevane arvelduse sünkroonimine võib luua selliseid arvestisündmusi:
Soovitus: hoidke sisemine pearaamat detailsem kui arve. Saate esitada arveid päevaste žetoonide kogusummade eest, säilitades samal ajal taotlustaseme kirjed toe, pettuste ülevaatuse, intressipiirangu häälestamise ja marginaali analüüsi jaoks.
Telegrami toimingud ilma Telegrami registreerimissüsteemi muutmata
Telegram on kasulik operaatori kiirete töövoogude jaoks: tugimeeskonnad juba märkavad sõnumeid, robotid saavad saata hoiatusi ja kliendid saavad sisselogimisjuhiseid ilma armatuurlauale sisse logimata. Kuid Telegram ei tohiks olla ainus arveldus-, turva- või tugiotsuste kontrolljälg.
Head Telegrami töövood hõlmavad järgmist:
- Madala saldo või suure kulu hoiatused 50%, 80% ja 95% ülempiirist.
- Uute klientide liitumissõnumid koos dokumentatsioonilinkide ja maskeeritud võtmenimedega.
- API-võtme pööramise teated enne ja pärast pööramist.
- Pakkuja katkestuse või halvenenud mudeli hoiatused.
- Inimtoe eskalatsioon, kui klient tabab korduvaid 401, 402, 403 või 429 vigu.
Fakt: Telegrami robotite API-kõned tehakse HTTPS-i kaudu robotimärgi lõpp-punktidesse ja Telegrami veebihaagid võivad sisaldada salajast loa päist, mis aitab veebihaagi päritolu kontrollida.
Soovitus: salvestage Telegrami vestluse ID-d rentniku metaandmetena, kuid ärge avaldage neid klientidele. Logige oma siseauditi logisse kõik roboti käivitatud haldustoimingud koos osaleja, ajatempli, kliendi, vana väärtuse, uue väärtuse ja põhjusega.
Turvalisuse ja isolatsiooni kontroll-loend
Enne juurdepääsu müümist testige üürniku isolatsiooni, nagu klient üritaks aktiivselt piire ületada.
- Klient A ei saa vaadata kliendi B API võtmeid.
- Klient A ei saa vaadata kliendi B kasutust, arveid, limiite, Telegrami vestluse ID-sid ega arvelduse olekut.
- Tühistatud võti nurjub kohe kõigil päringuteedel.
- Arveldamise peatatud klient ei saa jätkata kulutamist vahemällu salvestatud seansside või vanade võtmete kaudu.
- Klient ei saa taotleda mudeleid väljaspool määratud plaani.
- Hinnapiirangud kehtivad kliendi ja tööruumi, mitte ainult globaalse IP-aadressi järgi.
- Veebihaagi töötlejad kontrollivad allkirju või salapäiseid, kui neid toetatakse.
- Kõik ettevalmistused, piirangute muudatused, võtmete pööramised ja arveldamise alistamised loovad auditilogi kirjeid.
- Uuesti proovimise loogika kasutab idempotentsusvõtmeid, nii et dubleeritud taotlused ei esitaks klientidele topeltarvet.
- Tugitööriistad maskeerivad saladusi ja piiravad, kes saavad võtmeid paljastada või pöörata.
Prognoos: edasimüüjate portaalid konkureerivad üha enam juhtimise ja arvelduse selguse pärast, mitte ainult juurdepääsu pärast paljudele mudelitele. Kliendid ootavad standardfunktsioonidena projektipõhist kasutust, selgeid arveid, kiiret võtmete vaheldumist ja ranget kulukontrolli.
Peamised kompromissid, mille üle otsustada varakult
Ettemaks vs järelmaks
Ettemakstud saldod vähendavad krediidiriski ja muudavad kõvad piirid lihtsaks, kuid klientidele ei pruugi katkestused meeldida. Järelmaksuga arveldamine on väljakujunenud klientide jaoks sujuvam, kuid see nõuab krediidikontrolli, väljamaksete töövooge ja tugevamat anomaaliate tuvastamist.
Üks kombineeritud hind versus mudelipõhine hind
Segatud hinda on lihtsam selgitada. Mudelispetsiifiline hinnakujundus kaitseb marginaale ja soodustab tõhusat mudelivalikut. Kui pakute palju mudeleid, avaldage lihtne kliendile suunatud mudelikataloog ja peitke tarbetu pakkujaspetsiifiline keerukus.
Reaalajas mõõtmine versus viivitatud arveldamine
Reaalajas mõõtmine võimaldab kulupiiranguid ja ettemaksusaldosid. See nõuab ka püsivat kirjutamist, taasesituse käsitlemist ja leppimist. Viivitatud arveldamine on lihtsam, kuid see paneb teid enne piirangute jõustumist tegema suuri kulutusi.
Telegrami esmane tugi versus armatuurlaua tugi
Telegram on kiire ja paljudele operaatoritele tuttav. Armatuurlaud on parem kontrollitavuse, ekspordi, lubade ja klientide iseteeninduse jaoks. Kasutage teavituste ja kinnituste jaoks Telegrami, kuid salvestage kanooniline kirje oma süsteemi.
Tegutsetav levitamisplaan
- Alustage rentnike isoleerimisega: rakendage enne täpsemate arveldusfunktsioonide lisamist kliendi-, tööruumi-, võtme-, plaani- ja piirangukirjed.
- Ehitage lennueelset jõustamist: blokeerige tühistatud võtmed, peatatud arveldamine, keelatud mudelid ja piirake liiklust enne marsruutimist.
- Kasutusraamatu loomine: salvestage päringu ID-d, lubade arvud, kulud, edasimüüjate hinnad, olekud, ajatemplid ja idempotentsusvõtmed.
- Lisage vastavusseviimine: võrrelge enne arveldamist sisekasutust ülesvoolu pakkuja kogusummadega.
- Sünkrooni arvelduskokkuvõtted: saatke igapäevased või tunnised koondtulemused oma arveldusplatvormile stabiilsete klientide vastenduste ja idempotentsusvõtmetega.
- Traadiga telegrammi märguanded: alustage madala tasakaalu, katkestuse, võtmete pööramise ja toe eskalatsiooni teadetega.
- Käitage isolatsiooniteste: veenduge, et ükski klient ei pääse juurde teise kliendi võtmetele, kasutusviisidele, piirangutele, arvetele või vestluse metaandmetele.
Edasimüüjaportaal ei ole lihtsalt AI API ümbris. See on autentimise, rentnike poliitika, kasutusanalüütika, arveldamise ja toe töökiht. Esmalt koostage pearaamat ja limiidid, hoidke ülesvoolu võtmed serveri poolel ning muutke iga kliendile suunatud võti tühistatavaks, ulatuseks ja omistatavaks.