Byg en AI API-forhandlerportal: Lejerprovisionering, forbrugsmåling, fakturering og telegramoperationer
En praktisk referencearkitektur for bureauer, konsulenter og SaaS-byggere, der pakker AI API-adgang til kunder: lejerregistreringer, kundespecifikke nøgler, forbrugsgrænser, forbrugsregnskaber, faktureringssynkronisering og Telegram-operationer.
Hvis du pakker AI-adgang til klienter, skal du ikke give dem dine upstream-udbydernøgler. Byg et forhandlerlag, der udsteder nøgler med kundeomfang, håndhæver lejergrænser før hver anmodning, registrerer brugen i din egen finansbog og synkroniserer fakturerbare totaler til dit faktureringssystem.
Denne vejledning beskriver en praktisk driftsmodel for en AI API til bureauer, konsulenter og SaaS-byggere. Det er ikke et kundecasestudie. Det er en referencearkitektur, du kan tilpasse, uanset om du bruger en Partner API, en intern gateway eller en tilpasset proxy foran flere modeludbydere.
Forhandlerportalens arkitektur
En sikker forhandlerportal adskiller fire ansvarsområder:
- Partneradministration: din interne app til oprettelse af kunder, planer, nøgler, begrænsninger og supportarbejdsgange.
- Anmodningshåndhævelse: gatewaystien, der godkender kundenøgler, kontrollerer politik, sender anmodninger om ruter og blokerer overbegrænset trafik.
- Brugsregnskab: en holdbar finansbog, der registrerer forbrug og prisinput på anmodningsniveau.
- Fakturering og operationer: planlagt fakturasynkronisering, advarsler, meddelelser om nøglerotation og supporteskalering.
Et typisk flow ser sådan ud:
Partner Admin App
→ Partner API
→ kunde-/arbejdsområderegistreringer
→ kundespecifikke API-nøgler
→ plan-, model-, budget- og satsgrænser
→ anmod om gateway
→ forbrugsbog
→ faktureringssynkronisering
→ TelegrammeddelelsesbotFaktum: OpenAI anbefaler ikke at dele brugerbaserede API-nøgler til samarbejde og i stedet bruge projektbaserede nøgler, tildelte medlemmer og særskilte nøgler med isolerede satsgrænser og forbrugskontrol. OpenAIs servicevilkår forbyder også køb, salg eller overførsel af API-nøgler til eller fra en tredjepart. Disse fakta understøtter et forhandlerdesign, hvor upstream-legitimationsoplysningerne forbliver på serversiden, og kunderne modtager dine egne downstream-nøgler.
Anbefaling: Udsted én downstream-nøgle pr. kunde, projekt eller miljø. Genbrug ikke én kundenøgle på tværs af flere slutklienter. Udsæt ikke upstream-udbyderens legitimationsoplysninger i dokumentation, browserkode, mobilapps, logfiler eller klientsupportmeddelelser.
Lejerdatamodel
Lejermodellen bør gøre isolation eksplicit. Gem som minimum disse felter:
partner_id
kunde_id
workspace_id
api_key_id
plan_id
faktureringsstatus
spend_limit
rate_limit
tilladte_modeller
telegram_chat_id
usage_ledger_id
oprettet_at
updated_at
revoked_atI en større portal skal du tilføje felter for forudbetalt saldo, valuta, skatteområde, fakturakunde-id, supportniveau, misbrugsstatus og midlertidige tilsidesættelser.
Eksempel på kunderegistrering
Anbefaling: Behandl customer_id, workspace_id og api_key_id som separate begreber. En kunde kan have flere arbejdsområder, og hvert arbejdsområde kan have brug for separate produktions-, iscenesættelses- og udviklingsnøgler. Dette gør tilbagekaldelse, fejlretning og brugstilskrivning meget nemmere.
Onboarding-sekvens for en ny kunde
Et pålideligt onboarding-flow er kedeligt. Det bør producere de samme optegnelser hver gang og efterlade et revisionsspor.
- Opret kunden: Gem juridisk navn, faktureringskontakt, teknisk kontaktperson og intern ejer.
- Opret et arbejdsområde: adskil produktion fra test, om kunden vil integrere programmatisk.
- Tildel en plan: definer inkluderede modeller, markup, faktureringskadence og supportforventninger.
- Sæt grænser: Konfigurer forbrugslofter, anmodningsgrænser, tokengrænser og burst-politik.
- Opret API-nøgler: Udsted nøgler med omfang til kundens miljøer.
- Send integrationsinstruktioner: Angiv basis-URL, godkendelsesformat, modelliste, begrænsninger og supportkanal.
- Aktiver advarsler: tilslut Telegram eller en anden driftskanal for lav saldo, nøgle, udfald og faktureringsmeddelelser.
- Kør en testanmodning: bekræft godkendelse, brugsregistrering, modeladgang og fakturatilknytning.
Anbefaling: gør onboarding idempotent. Hvis din admin-app gentager en "opret kunde"-handling, bør den ikke oprette dublerede faktureringsposter eller dublere API-nøgler. Brug eksterne id'er og idempotensnøgler til at klargøre opkald.
Anmodningstidsbudgetkontrol
Den vigtigste håndhævelse sker, før anmodningen når en opstrømsmodel. Din gateway bør først opdage, at en kunde overskrider budgettet, efter at udbyderen allerede har debiteret dig.
Brug denne preflight-sekvens:
- Godkend downstream API-nøglen.
- Løs
partner_id,customer_idogworkspace_id. - Tjek, om nøglen er aktiv og ikke tilbagekaldt.
- Tjek faktureringsstatus: aktiv, prøve, forudbetalt, sat på pause, forfalden eller suspenderet.
- Tjek det faste forbrugsloft for den aktuelle faktureringsperiode.
- Tjek hastighedsgrænser, såsom anmodninger pr. minut og tokens pr. dag.
- Tjek, om den ønskede model er tilladt for kundens plan.
- Estimer maksimalt mulige omkostninger fra model, maks. tokens og anmodningsparametre.
- Rotér kun anmodningen, hvis politikken godkendes.
if key.revoked:
reject(401, "API-nøgle tilbagekaldt")
if customer.billing_status i ["pauseret", "suspenderet", "forfalden"]:
reject(402, "Faktureringsstatus tillader ikke brug")
if requested_model ikke i customer.allowed_models:
reject(403, "Model ikke aktiveret for dette arbejdsområde")
if current_period_spend + estimated_max_cost > customer.hard_cap:
reject(402, "forbrugsgrænse overskredet")
if rate_limit_exceeded(customer_id, requested_model):
afvis(429, "Satsgrænse overskredet")
route_request()Fakta: OWASP API Security Top 10 2023 kalder godkendelse af brudte objekter, brudt godkendelse og ubegrænset ressourceforbrug som store API-risici. Disse kortlægges direkte til forhandlerportaler: én lejer må ikke læse en anden lejers data, nøgler må ikke kunne omgås, og én kunde må ikke være i stand til at oprette ubegrænset udbyderforbrug.
Afvejning: strenge hårde hætter beskytter din margen, men de kan afbryde legitime spidser. Et godt kompromis er en midlertidig tilsidesættelse af workflow med en udløbstid, godkender, årsag og revisionslogpost.
Brugsbog som kilde til sandhed
For adgangskontrol i realtid skal du opbevare din egen forbrugsbog. Eksterne faktureringsværktøjer er fremragende til fakturering, men de er normalt ikke det rigtige sted at træffe beslutninger på millisekundniveau, tillade eller afvise.
En brugshændelse skal fange nok detaljer til at afstemme udbyderfakturaer, forklare kunderegninger og fejlfinde tvister:
Optag også mislykkede anmodninger, men skeln fejl, der kan faktureres, fra fejl, der ikke er det. Udbydertimeouts, valideringsfejl, kundeannulleringer, genforsøg og sikkerhedsblokeringer kan have forskellige regnskabsmæssige resultater afhængigt af, hvornår de opstår.
Anbefaling: Skriv en afventende finanshændelse, når anmodningen er accepteret, og afslut den, når tokenbrug og -omkostninger er kendt. Dette giver dig mulighed for at reservere budget før routing og derefter rette det endelige beløb efter færdiggørelse.
Afstemningsmønster
- Gem hændelser på anmodningsniveau i den interne finans.
- Samlet brug efter kunde, model og faktureringsperiode.
- Sammenlign interne totaler med upstream-udbyderfakturaer eller brugseksporter.
- Undersøg væsentlige forskelle, før du udsteder fakturaer.
- Synkroniser opsummeret fakturerbar brug med faktureringssystemet.
Afvejning: Synkronisering af opsummeret brug reducerer mængden og kompleksiteten af faktureringshændelser, men det kan gøre kundefakturaer mindre detaljerede. Hvis kunder har brug for rapportering på modelniveau eller projektniveau, skal du bevare disse dimensioner i din faktureringssynkronisering eller kundebetjeningspanel.
Faktureringssynkronisering med brugsbaserede målere
Brugsbaserede faktureringssystemer følger generelt et mønster: definer produkter og priser, indtag brugshændelser, aggregér dem over en faktureringsperiode, generer fakturaer og overvåg fejl. Stripe Billing understøtter f.eks. målerhændelser med et hændelsesnavn, kunde-id, numerisk værdi, valgfrit tidsstempel, valgfri idempotens-id og valgfri dimensioner.
For AI API-fakturering er almindelige målervalg:
- Token i alt: nyttigt, når priserne er tæt knyttet til input- og output-tokens.
- Antal forespørgsler: nyttigt til simple planer eller lav-token API-kald.
- Modelspecifikke enheder: nyttigt, når premium-modeller har forskellige marginer.
- Sæder eller aktive arbejdsområder: nyttigt til hybride SaaS-plus-brugsplaner.
Faktum: Stripe-målere understøtter aggregeringsformler som sum, count og last. Disse kort til tokentotaler, anmodningstællinger og tilstandslignende værdier, såsom pladser eller aktive grænser.
En daglig faktureringssynkronisering kan skabe målerhændelser som denne:
Anbefaling: Hold den interne finans mere detaljeret end fakturaen. Du kan fakturere daglige tokentotaler, mens du stadig beholder rekorder på anmodningsniveau til support, svindelgennemgang, justering af satsgrænser og marginanalyse.
Telegram-operationer uden at gøre Telegram til registreringssystemet
Telegram er nyttigt til hurtige operatørarbejdsgange: supportteams bemærker allerede beskeder, bots kan sende advarsler, og kunder kan modtage onboarding-instruktioner uden at logge ind på et dashboard. Men Telegram bør ikke være det eneste revisionsspor for beslutninger om fakturering, sikkerhed eller support.
Gode Telegram-arbejdsgange omfatter:
- Lavsaldo eller høje forbrugsadvarsler ved 50 %, 80 % og 95 % af et loft.
- Beskeder om onboarding af nye kunder med dokumentationslinks og maskerede nøglenavne.
- Meddelelser om API-nøglerotation før og efter rotation.
- Udbyderudfald eller underretninger om forringet model.
- Eskalering af menneskelig support, når en kunde rammer gentagne 401-, 402-, 403- eller 429-fejl.
Faktum: Telegram Bot API-kald foretages over HTTPS til bot-token-slutpunkter, og Telegram-webhooks kan inkludere en hemmelig token-header for at hjælpe med at bekræfte webhook-oprindelsen.
Anbefaling: Gem Telegram-chat-id'er som lejermetadata, men udsæt dem ikke på tværs af kunder. Log alle bot-udløste administrative handlinger i din interne revisionslog med aktør, tidsstempel, kunde, gammel værdi, ny værdi og årsag.
Tjekliste for sikkerhed og isolation
Før du sælger adgang, skal du teste lejerisolering, som om en kunde aktivt forsøger at krydse grænser.
- Kunde A kan ikke se Kunde B API-nøgler.
- Kunde A kan ikke se kunde B-brug, fakturaer, grænser, Telegram-chat-id'er eller faktureringsstatus.
- En tilbagekaldt nøgle mislykkes med det samme på alle anmodningsstier.
- En kunde, der er sat på pause, kan ikke fortsætte med at bruge gennem cachelagrede sessioner eller gamle nøgler.
- En kunde kan ikke anmode om modeller uden for den tildelte plan.
- Satsgrænser gælder efter kunde og arbejdsområde, ikke kun efter global IP-adresse.
- Webhook-handlere bekræfter signaturer eller hemmelige overskrifter, hvor de understøttes.
- Alle klargøring, grænseændringer, nøglerotationer og faktureringstilsidesættelser skaber revisionslogposter.
- Prøv igen logik bruger idempotensnøgler, så duplikerede anmodninger ikke dobbeltfakturerer kunder.
- Supportværktøjer maskerer hemmeligheder og begrænser, hvem der kan afsløre eller rotere nøgler.
Forudsigelse: forhandlerportaler vil i stigende grad konkurrere på styring og faktureringsklarhed, ikke kun på adgang til mange modeller. Kunder vil forvente brug pr. projekt, klare fakturaer, hurtig nøglerotation og kontrol med hårde udgifter som standardfunktioner.
Vigtige afvejninger at beslutte tidligt
Forudbetalt versus efterbetalt
Forudbetalte saldi reducerer kreditrisikoen og gør hårde afskæringer ligetil, men kunder kan ikke lide afbrydelser. Efterbetalt fakturering er nemmere for etablerede kunder, men det kræver kredittjek, rykkende arbejdsgange og stærkere registrering af uregelmæssigheder.
Én blandet pris i forhold til modelspecifik pris
En blandet pris er nemmere at forklare. Modelspecifik prissætning beskytter marginer og tilskynder til effektiv modeludvælgelse. Hvis du tilbyder mange modeller, skal du udgive et enkelt kundevendt modelkatalog og skjule unødvendig udbyderspecifik kompleksitet.
Realtidsmåling kontra forsinket fakturering
Realtidsmåling muliggør forbrugslofter og forudbetalte saldi. Det kræver også holdbare skrivninger, genspilshåndtering og afstemning. Forsinket fakturering er enklere, men det udsætter dig for løbsk forbrug, før grænserne træder i kraft.
Telegram-først-support versus dashboard-først-support
Telegram er hurtigt og velkendt for mange operatører. Et dashboard er bedre til revision, eksport, tilladelser og kundeselvbetjening. Brug Telegram til meddelelser og godkendelser, men gem den kanoniske post i dit system.
Handlingsplan for udrulning
- Start med lejerisolering: implementer kunde-, arbejdsområde-, nøgle-, plan- og begrænsningsregistreringer, før du tilføjer avancerede faktureringsfunktioner.
- Byg håndhævelse på forhånd: bloker tilbagekaldte nøgler, suspenderet fakturering, forbudte modeller, og overbegræns trafikken før routing.
- Opret forbrugsregnskabet: Registrer anmodnings-id'er, tokenantal, omkostninger, forhandlerpriser, statusser, tidsstempler og idempotensnøgler.
- Tilføj afstemning: sammenlign internt forbrug med upstream-udbydertotaler før fakturering.
- Synkroniser faktureringsoversigter: Send daglige eller timemæssige aggregater til din faktureringsplatform med stabile kundetilknytninger og idempotensnøgler.
- Telegram-advarsler via ledning: start med beskeder om lav balance, udfald, nøglerotation og understøttelse af eskalering.
- Kør isolationstest: bekræft, at ingen kunde kan få adgang til en anden kundes nøgler, brug, grænser, fakturaer eller chatmetadata.
En forhandlerportal er ikke bare en indpakning omkring en AI API. Det er et driftslag for godkendelse, lejerpolitik, brugsanalyse, fakturering og support. Byg regnskabet og grænserne først, behold opstrømsnøgler på serversiden, og gør alle kundevendte nøgler tilbagekaldelige, omfangsrige og henførbare.