Bouw een AI API-resellerportaal: huurdersvoorziening, gebruiksmeting, facturering en Telegram-activiteiten

Als u AI-toegang voor klanten verpakt, geef ze dan niet de sleutels van uw upstreamprovider. Bouw een resellerlaag die klantspecifieke sleutels uitgeeft, tenantlimieten afdwingt vóór elk verzoek, het gebruik in uw eigen grootboek registreert en de factureerbare totalen synchroniseert met uw factureringssysteem.

Deze handleiding beschrijft een praktisch werkingsmodel voor een AI API voor bureaus, consultants en SaaS-bouwers. Het is geen klantcasestudy. Het is een referentiearchitectuur die u kunt aanpassen, of u nu een Partner API, een interne gateway of een aangepaste proxy voor meerdere modelproviders gebruikt.

De architectuur van het resellerportaal

Een veilig resellerportaal onderscheidt vier verantwoordelijkheden:

• Partnerbeheer: uw interne app voor het maken van klanten, plannen, sleutels, limieten en ondersteuningsworkflows.
• Verzoekhandhaving: het gatewaypad dat klantsleutels verifieert, het beleid controleert, verzoeken routert en verkeer boven de limiet blokkeert.
• Gebruiksboekhouding: een duurzaam grootboek dat het gebruik en de prijsinvoer op verzoekniveau registreert.
• Facturering en bewerkingen: geplande factuursynchronisatie, waarschuwingen, kennisgevingen van sleutelrotatie en escalatie van ondersteuning.

Een typische stroom ziet er als volgt uit:

Partnerbeheerder-app
  → Partner-API
    → klant-/werkruimteregistratie
    → klantgerichte API-sleutels
    → plan-, model-, budget- en tarieflimieten
    → gateway aanvragen
    → gebruiksgrootboek
    → factureringssynchronisatie
    → Telegram-meldingsbot

Feit: OpenAI raadt aan om op gebruikers gebaseerde API-sleutels voor samenwerking niet te delen en in plaats daarvan projectgebaseerde sleutels, toegewezen leden en afzonderlijke sleutels met geïsoleerde tarieflimieten en uitgavencontroles te gebruiken. De servicevoorwaarden van OpenAI verbieden ook het kopen, verkopen of overdragen van API-sleutels aan of van een derde partij. Deze feiten ondersteunen een resellerontwerp waarbij upstream-referenties aan de serverzijde blijven en klanten uw eigen downstream-sleutels ontvangen.

Aanbeveling: geef één downstream-sleutel per klant, project of omgeving uit. Gebruik één klantsleutel niet voor meerdere eindklanten. Maak de inloggegevens van de upstream-provider niet openbaar in documentatie, browsercode, mobiele apps, logboeken of klantondersteuningsberichten.

Tenantgegevensmodel

Het tenantmodel moet isolatie expliciet maken. Bewaar minimaal deze velden:

partner_id
klant_id
werkruimte_id
api_key_id
plan_id
factureringsstatus
bestedingslimiet
tarief_limiet
toegestane_modellen
telegram_chat_id
gebruik_grootboek_id
aangemaakt_at
bijgewerkt_at
ingetrokken_at

Voeg in een grotere portal velden toe voor prepaid-saldo, valuta, belastingregio, factuurklant-ID, ondersteuningsniveau, misbruikstatus en tijdelijke overschrijvingen.

Voorbeeld klantrecord

{
  "partner_id": "partner_123",
  "customer_id": "cust_acme",
  "workspace_id": "ws_prod",
  "plan_id": "groei_api",
  "billing_status": "actief",
  "bestedingslimiet": {
    "periode": "maand",
    "hard_cap_usd": 500,
    "alert_thresholds": [0,5, 0,8, 0,95]
  },
  "rate_limit": {
    "verzoeken_per_minuut": 120,
    "tokens_per_dag": 2000000
  },
  "allowed_models": ["snelle chat", "redeneringsstandaard"],
  "telegram_chat_id": "-1001234567890",
  "usage_ledger_id": "ledger_cust_acme"

Aanbeveling: behandel customer_id, workspace_id en api_key_id als afzonderlijke concepten. Een klant kan meerdere werkruimten hebben en elke werkruimte heeft mogelijk afzonderlijke productie-, staging- en ontwikkelingssleutels nodig. Dit maakt intrekking, foutopsporing en gebruikstoeschrijving veel eenvoudiger.

Introductieprocedure voor een nieuwe klant

Een betrouwbare onboarding-flow is saai van opzet. Het moet elke keer dezelfde gegevens opleveren en een audittrail achterlaten.

1. Maak de klant aan: wettelijke naam, contactpersoon voor facturering, technische contactpersoon en interne eigenaar.
2. Creëer een werkruimte: scheid productie van testen als de klant programmatisch wil integreren.
3. Wijs een plan toe: definieer de inbegrepen modellen, toeslagen, factureringsfrequentie en ondersteuningsverwachtingen.
4. Limieten instellen: configureer bestedingslimieten, verzoeklimieten, tokenlimieten en burst-beleid.
5. API-sleutels maken: sleutels met een bereik uitgeven voor de omgevingen van de klant.
6. Integratie-instructies verzenden: geef de basis-URL, het authenticatieformaat, de modellijst, limieten en ondersteuningskanaal op.
7. Schakel waarschuwingen in: verbind Telegram of een ander operationeel kanaal voor meldingen over een laag saldo, sleutel, uitval en facturering.
8. Voer een testverzoek uit: verifieer authenticatie, gebruiksregistratie, modeltoegang en factuurtoewijzing.

Aanbeveling: maak onboarding idempotent. Als uw beheerdersapp opnieuw de bewerking 'Klant aanmaken' probeert, mogen er geen dubbele factureringsrecords of dubbele API-sleutels worden gemaakt. Gebruik externe ID's en idempotentiesleutels voor het inrichten van oproepen.

Budgetbeheer op aanvraagtijd

De belangrijkste handhaving vindt plaats voordat het verzoek een upstream-model bereikt. Uw gateway mag niet ontdekken dat een klant het budget heeft overschreden nadat de provider u al kosten in rekening heeft gebracht.

Gebruik deze preflight-reeks:

1. Authenticeer de downstream API-sleutel.
2. Los partner_id, klant_id en workspace_id op.
3. Controleer of de sleutel actief is en niet is ingetrokken.
4. Controleer de factureringsstatus: actief, op proef, prepaid, onderbroken, te laat of opgeschort.
5. Controleer de harde bestedingslimiet voor de huidige factureringsperiode.
6. Controleer de snelheidslimieten, zoals verzoeken per minuut en tokens per dag.
7. Controleer of het gevraagde model is toegestaan voor het abonnement van de klant.
8. Schat de maximaal mogelijke kosten op basis van het model, het maximale aantal tokens en de verzoekparameters.
9. Route het verzoek alleen door als het beleid wordt goedgekeurd.

als sleutel.ingetrokken:
    afwijzen(401, "API-sleutel ingetrokken")
if customer.billing_status in ["gepauzeerd", "opgeschort", "achterstallig"]:
    weigeren(402, "Factureringsstatus staat gebruik niet toe")
indien aangevraagd_model niet in customer.allowed_models:
    weigeren(403, "Model is niet ingeschakeld voor deze werkruimte")
als huidige_periode_besteding + geschatte_max_kosten > klant.harde_cap:
    afwijzen(402, "Bestedingslimiet overschreden")
if rate_limit_exceeded(klant_id, aangevraagd_model):
    afwijzen(429, "Tarieflimiet overschreden")
route_request()

Feit: OWASP API Security Top 10 2023 noemt kapotte objectautorisatie, kapotte authenticatie en onbeperkt gebruik van bronnen als grote API-risico's. Deze verwijzen rechtstreeks naar resellerportals: één huurder mag de gegevens van een andere huurder niet lezen, sleutels mogen niet kunnen worden omzeild en één klant mag geen onbeperkte provideruitgaven kunnen creëren.

Afruil: strikte harde caps beschermen uw marge, maar kunnen legitieme pieken onderbreken. Een goed compromis is een tijdelijke overschrijvingsworkflow met een vervaltijd, goedkeurder, reden en invoer in het auditlogboek.

Gebruik het grootboek als bron van waarheid

Voor realtime toegangscontrole houdt u uw eigen gebruiksgrootboek bij. Externe factureringstools zijn uitstekend geschikt voor facturering, maar zijn meestal niet de juiste plek om op millisecondenniveau beslissingen te nemen over toestaan of weigeren.

Een gebruiksgebeurtenis moet voldoende details bevatten om leveranciersfacturen te kunnen afstemmen, klantrekeningen uit te leggen en geschillen op te lossen:

{
  "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": "redeneerstandaard",
  "invoer_tokens": 1850,
  "output_tokens": 420,
  "cached_tokens": 1200,
  "provider_kosten": 0,0142,
  "reseller_price": 0,0230,
  "valuta": "USD",
  "tijdstempel": "2026-08-02T10:15:30Z",
  "status": "geslaagd"

Registreer ook mislukte verzoeken, maar maak onderscheid tussen fouten die factureerbaar zijn en fouten die dat niet zijn. Time-outs van providers, validatiefouten, annuleringen van klanten, nieuwe pogingen en veiligheidsblokkeringen kunnen verschillende boekhoudkundige uitkomsten hebben, afhankelijk van wanneer ze zich voordoen.

Aanbeveling: schrijf een grootboekgebeurtenis die in behandeling is wanneer het verzoek wordt geaccepteerd, en voltooi deze vervolgens wanneer het tokengebruik en de kosten bekend zijn. Hierdoor kunt u budget reserveren voordat u het doorstuurt en na voltooiing het eindbedrag corrigeren.

Afstemmingspatroon

1. Sla gebeurtenissen op verzoekniveau op in het interne grootboek.
2. Aggregeer het gebruik per klant, model en factureringsperiode.
3. Vergelijk interne totalen met facturen van upstream-providers of gebruiksexports.
4. Onderzoek materiële verschillen voordat u facturen uitreikt.
5. Synchroniseer het samengevatte factureerbare gebruik met het factureringssysteem.

Trade-off: het synchroniseren van samengevat gebruik vermindert het volume en de complexiteit van factureringsgebeurtenissen, maar kan klantfacturen minder gedetailleerd maken. Als klanten rapportage op model- of projectniveau nodig hebben, bewaar deze dimensies dan in uw factureringssynchronisatie of klantendashboard.

Factureringssynchronisatie met op gebruik gebaseerde meters

Op gebruik gebaseerde factureringssystemen volgen over het algemeen een patroon: producten en prijzen definiëren, gebruiksgebeurtenissen opnemen, deze samenvoegen over een factureringsperiode, facturen genereren en fouten monitoren. Stripe Billing ondersteunt bijvoorbeeld metergebeurtenissen met een gebeurtenisnaam, klant-ID, numerieke waarde, optionele tijdstempel, optionele idempotentie-ID en optionele dimensies.

Voor AI API-facturering zijn de gebruikelijke meterkeuzes:

• Tokentotaal: handig als prijzen nauw verband houden met invoer- en uitvoertokens.
• Aantal verzoeken: handig voor eenvoudige plannen of API-aanroepen met weinig token.
• Modelspecifieke eenheden: handig als premiummodellen verschillende marges hebben.
• Stoelen of actieve werkplekken: handig voor hybride SaaS-plus-gebruiksabonnementen.

Feit: Streepmeters ondersteunen aggregatieformules zoals som, aantal en laatste. Deze wijzen op tokentotalen, aantal aanvragen en statusachtige waarden zoals zitplaatsen of actieve limieten.

Bij een dagelijkse factureringssynchronisatie kunnen metergebeurtenissen als deze ontstaan:

{
  "event_name": "ai_tokens_used",
  "klant": "stripe_customer_456",
  "waarde": 2270000,
  "tijdstempel": "2026-08-02T23:59:00Z",
  "idempotency_key": "cust_acme_2026-08-02_tokens",
  "afmetingen": {
    "plan": "groei_api",
    "model_family": "standaard"
  }

Aanbeveling: houd het interne grootboek gedetailleerder dan de factuur. U kunt dagelijkse tokentotalen factureren terwijl u nog steeds records op aanvraagniveau bewaart voor ondersteuning, fraudebeoordeling, afstemming van tarieflimieten en margeanalyse.

Telegrambewerkingen zonder Telegram tot registratiesysteem te maken

Telegram is handig voor snelle workflows van operators: ondersteuningsteams merken berichten al op, bots kunnen waarschuwingen verzenden en klanten kunnen onboarding-instructies ontvangen zonder in te loggen op een dashboard. Maar Telegram mag niet het enige audittraject zijn voor beslissingen over facturering, beveiliging of ondersteuning.

Goede Telegram-workflows zijn onder meer:

• Meldingen met een laag saldo of hoge uitgaven bij 50%, 80% en 95% van een limiet.
• Onboardingberichten voor nieuwe klanten met documentatielinks en gemaskeerde sleutelnamen.
• Mededeling van API-sleutelrotatie voor en na rotatie.
• Waarschuwingen voor uitval van providers of defecte modellen.
• Escalatie van menselijke ondersteuning wanneer een klant herhaaldelijk 401-, 402-, 403- of 429-fouten tegenkomt.

Feit: Telegram Bot API-aanroepen worden via HTTPS gedaan naar bot-token-eindpunten, en Telegram-webhooks kunnen een geheime token-header bevatten om de oorsprong van de webhook te helpen verifiëren.

Aanbeveling: bewaar Telegram-chat-ID's als metadata van huurders, maar maak ze niet openbaar aan klanten. Registreer elke door een bot geactiveerde administratieve actie in uw interne auditlogboek met actor, tijdstempel, klant, oude waarde, nieuwe waarde en reden.

Checklist voor beveiliging en isolatie

Test voordat u toegang verkoopt de huurderisolatie alsof een klant actief grenzen probeert te overschrijden.

• Klant A kan de API-sleutels van klant B niet bekijken.
• Klant A kan het gebruik, de facturen, de limieten, de Telegram-chat-ID's of de factuurstatus van klant B niet bekijken.
• Een ingetrokken sleutel mislukt onmiddellijk op alle verzoekpaden.
• Een klant waarbij de facturering is onderbroken, kan niet doorgaan met uitgeven via in het cachegeheugen opgeslagen sessies of oude sleutels.
• Een klant kan geen modellen aanvragen buiten het toegewezen abonnement.
• Tarieflimieten gelden per klant en werkruimte, niet alleen per globaal IP-adres.
• Webhook-handlers verifiëren handtekeningen of geheime headers, indien ondersteund.
• Alle registraties, limietwijzigingen, sleutelroulaties en factureringsoverschrijvingen creëren controlelogboekvermeldingen.
• Logica voor opnieuw proberen maakt gebruik van idempotentiesleutels, zodat dubbele verzoeken klanten niet dubbel factureren.
• Ondersteuningstools maskeren geheimen en beperken wie sleutels kan onthullen of roteren.

Voorspelling: resellerportals zullen steeds meer concurreren op het gebied van bestuur en duidelijkheid over facturering, en niet alleen op het gebied van toegang tot veel modellen. Klanten verwachten gebruik per project, duidelijke facturen, snelle sleutelrotatie en harde controle over de uitgaven als standaardfuncties.

Belangrijke afwegingen om vroegtijdig te beslissen

Prepaid versus postpaid

Voorafbetaalde saldi verminderen het kredietrisico en maken harde afsluitingen eenvoudig, maar klanten houden misschien niet van onderbrekingen. Postpaid-facturering verloopt soepeler voor gevestigde klanten, maar vereist kredietcontroles, aanmaningsworkflows en sterkere detectie van afwijkingen.

Eén gemengde prijs versus modelspecifieke prijzen

Een gemengde prijs is gemakkelijker uit te leggen. Modelspecifieke prijzen beschermen de marges en stimuleren een efficiënte modelselectie. Als u veel modellen aanbiedt, publiceer dan een eenvoudige, klantgerichte modellencatalogus en verberg onnodige providerspecifieke complexiteit.

Realtime metingen versus uitgestelde facturering

Realtime metingen maken bestedingslimieten en prepaid-saldo's mogelijk. Het vereist ook duurzame schrijfbewerkingen, afhandeling van herhalingen en afstemming. Uitgestelde facturering is eenvoudiger, maar u loopt wel risico op uitgaven voordat de limieten van kracht worden.

Telegram-eerste ondersteuning versus dashboard-eerste ondersteuning

Telegram is voor veel operators snel en vertrouwd. Een dashboard is beter voor de controleerbaarheid, export, machtigingen en zelfbediening voor klanten. Gebruik Telegram voor meldingen en goedkeuringen, maar bewaar het canonieke record in uw systeem.

Bruikbaar implementatieplan

1. Begin met huurderisolatie: implementeer klant-, werkruimte-, sleutel-, plan- en limietrecords voordat u geavanceerde factureringsfuncties toevoegt.
2. Voer preflighthandhaving in: blokkeer ingetrokken sleutels, opgeschorte facturering, niet-toegestane modellen en overbeperk het verkeer vóór routering.
3. Maak het gebruiksgrootboek: registreer verzoek-ID's, tokenaantallen, kosten, resellerprijzen, statussen, tijdstempels en idempotentiesleutels.
4. Voeg afstemming toe: vergelijk het interne gebruik met de totalen van de upstream-provider voordat u factureert.
5. Synchroniseer factuuroverzichten: stuur dagelijkse of uurlijkse totalen naar uw factureringsplatform met stabiele klanttoewijzingen en idempotentiesleutels.
6. Wire Telegram-waarschuwingen: begin met berichten over een laag saldo, uitval, sleutelrotatie en ondersteuningsescalatie.
7. Voer isolatietests uit: controleer of geen enkele klant toegang heeft tot de sleutels, het gebruik, de limieten, de facturen of de chatmetadata van een andere klant.

Een resellerportal is niet alleen maar een omhulsel rond een AI API. Het is een operationele laag voor authenticatie, huurdersbeleid, gebruiksanalyse, facturering en ondersteuning. Bouw eerst het grootboek en de limieten op, bewaar upstream-sleutels aan de serverzijde en zorg ervoor dat elke klantgerichte sleutel herroepbaar, scoped en toewijsbaar is.

Gerelateerd lezen

• Isolatie en rotatie van API-sleutels praktijken
• AI API-kostenbeheersingstechnieken
• failure-aware routing en nieuwe pogingen