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

Als u AI-toegang voor klanten verpakt, geef ze dan niet uw upstreamprovidersleutels. 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 operationeel model 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, beleid controleert, verzoeken routert en verkeer boven de limiet blokkeert.
• Gebruiksboekhouding: een duurzaam grootboek waarin het gebruik en de prijsinvoer op verzoekniveau worden geregistreerd.
• Facturering en bewerkingen: geplande factuursynchronisatie, waarschuwingen, kennisgevingen van sleutelrotatie en escalatie van ondersteuning.

Een typische stroom ziet er als volgt uit:

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

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 uit per klant, project of omgeving. 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. Sla minimaal deze velden op:

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

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

Voorbeeldklantrecord

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

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 betrouwbaar onboardingproces is saai van opzet. Het moet elke keer dezelfde records opleveren en een audittrail achterlaten.

1. Maak de klant: winkelnaam, contactpersoon voor facturering, technische contactpersoon en interne eigenaar.
2. Maak een werkruimte: scheid productie van testen als de klant programmatisch wil integreren.
3. Een abonnement toewijzen: definieer de inbegrepen modellen, toeslagen, factureringsfrequentie en ondersteuningsverwachtingen.
4. Limieten instellen: configureer bestedingslimieten, verzoeklimieten, tokenlimieten en burst-beleid.
5. Maak API sleutels: geef sleutelsleutels uit voor de omgevingen van de klant.
6. Integratie-instructies verzenden: geef basis-URL, authenticatie-indeling, modellijst, limieten en ondersteuningskanaal op.
7. Meldingen inschakelen: connect Telegram of een ander operationeel kanaal voor meldingen over een laag saldo, sleutel, storing en facturering.
8. Voer een testverzoek uit: verifieer de authenticatie, gebruiksregistratie, modeltoegang en factuurtoewijzing.

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

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. Oplossing partner_id, customer_id en workspace_id.
3. Controleer of de sleutel actief is en niet is ingetrokken.
4. Controleer de factureringsstatus: actief, op proef, vooraf betaald, 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 aangevraagde model is toegestaan voor het abonnement van de klant.
8. Schat de maximaal mogelijke kosten op basis van model, maximale tokens en verzoekparameters.
9. Route het verzoek alleen door als het beleid wordt goedgekeurd.

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()

Feit: OWASP API Beveiliging Top 10 2023 noemt defecte objectautorisatie, defecte authenticatie en onbeperkt brongebruik 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.

Afweging: strikte harde limieten 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.

Gebruiksgrootboek 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": "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"
}

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 lopende grootboekgebeurtenis 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 vervolgens het eindbedrag na voltooiing corrigeren.

Afstemmingspatroon

1. Sla gebeurtenissen op verzoekniveau op in het interne grootboek.
2. Totaalgebruik 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: definieer producten en prijzen, neem gebruiksgebeurtenissen op, verzamel ze over een factureringsperiode, genereer facturen en controleer fouten. 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 abonnementen of API oproepen met weinig token.
• Modelspecifieke eenheden: handig als premiummodellen verschillende marges hebben.
• Stoelen of actieve werkruimten: handig voor hybride SaaS-plus-gebruiksabonnementen.

Feit: Stripe-meters ondersteunen aggregatieformules zoals som, aantal en laatste. Deze verwijzen naar tokentotalen, aantal verzoeken en statusachtige waarden zoals zitplaatsen of actieve limieten.

Bij een dagelijkse factureringssynchronisatie kunnen metergebeurtenissen als deze ontstaan:

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

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.

Telegram bewerkingen zonder Telegram het registratiesysteem

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 omvatten:

• Meldingen met een laag saldo of hoge uitgaven bij 50%, 80% en 95% van een limiet.
• Introductieberichten voor nieuwe klanten met documentatielinks en gemaskeerde sleutelnamen.
• API-sleutelrotatiemeldingen 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 gedaan via HTTPS naar bot-token-eindpunten, en Telegram webhooks kunnen een geheime token-header bevatten om de oorsprong van de webhook te helpen verifiëren.

Aanbeveling: sla Telegram chat-ID's op als metadata van tenants, 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 sleutels van klant B API niet bekijken.
• Klant A kan het gebruik, de facturen, de limieten, Telegram chat-ID's of de factuurstatus van klant B niet bekijken.
• Een ingetrokken sleutel mislukt onmiddellijk op alle verzoekpaden.
• Een klant met een factureringspauze 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 beheer 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 vroeg te beslissen

Prepaid versus postpaid

Vooruitbetaalde 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 je veel modellen aanbiedt, publiceer dan een eenvoudige, klantgerichte modellencatalogus en verberg onnodige providerspecifieke complexiteit.

Realtime metingen versus uitgestelde facturering

Realtime meting maakt 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 snel en vertrouwd voor veel operators. Een dashboard is beter voor de controleerbaarheid, export, machtigingen en zelfbediening voor klanten. Gebruik Telegram voor meldingen en goedkeuringen, maar bewaar de canonieke record in uw systeem.

Bruikbaar implementatieplan

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

Een resellerportaal 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, bereikbaar en toewijsbaar is.

Gerelateerd lezen

• API sleutelisolatie- en rotatiepraktijken
• AI API kostenbeheersing technieken
• Foutbewuste routering en nieuwe pogingen