Bygg en AI API-återförsäljarportal: Provisionering av hyresgäster, användningsmätning, fakturering och telegramoperationer

Om du paketerar AI-åtkomst för klienter ska du inte ge dem dina uppströmsleverantörsnycklar. Bygg ett återförsäljarlager som utfärdar nycklar med kundomfattning, upprätthåller hyresgästgränser före varje förfrågan, registrerar användning i din egen reskontra och synkroniserar fakturerbara summor till ditt faktureringssystem.

Den här guiden beskriver en praktisk driftsmodell för ett AI API för byråer, konsulter och SaaS-byggare. Det är inte en kundfallsstudie. Det är en referensarkitektur som du kan anpassa oavsett om du använder ett Partner API, en intern gateway eller en anpassad proxy inför flera modellleverantörer.

Återförsäljarportalens arkitektur

En säker återförsäljarportal skiljer fyra ansvarsområden åt:

• Partneradministration: din interna app för att skapa kunder, planer, nycklar, gränser och supportarbetsflöden.
• Begär efterlevnad: gatewaysökvägen som autentiserar kundnycklar, kontrollerar policy, skickar förfrågningar och blockerar övergränsad trafik.
• Användningsredovisning: en hållbar reskontra som registrerar användning på begäran och prissättning.
• Fakturering och operationer: schemalagd fakturasynkronisering, varningar, meddelanden om nyckelrotation och supporteskalering.

Ett typiskt flöde ser ut så här:

Partner Admin App
  → Partner API
    → kund-/arbetsplatsposter
    → kundanpassade API-nycklar
    → plan-, modell-, budget- och prisgränser
    → begär gateway
    → användningsreskontra
    → faktureringssynkronisering
    → Telegramaviseringsbot

Fakta: OpenAI rekommenderar att du inte delar användarbaserade API-nycklar för samarbete och istället använder projektbaserade nycklar, tilldelade medlemmar och distinkta nycklar med isolerade prisgränser och utgiftskontroller. OpenAI:s tjänstevillkor förbjuder också köp, försäljning eller överföring av API-nycklar till eller från en tredje part. Dessa fakta stöder en återförsäljardesign där uppströmsreferenserna förblir serversidan och kunderna får dina egna nedströmsnycklar.

Rekommendation: utfärda en nedströmsnyckel per kund, projekt eller miljö. Återanvänd inte en kundnyckel över flera slutkunder. Exponera inte uppströmsleverantörsuppgifter i dokumentation, webbläsarkod, mobilappar, loggar eller klientsupportmeddelanden.

Modell för hyresgästdata

Hyresgästmodellen bör göra isolering explicit. Lagra åtminstone dessa fält:

partner_id
kund_id
workspace_id
api_key_id
plan_id
faktureringsstatus
spend_limit
rate_limit
tillåtna_modeller
telegram_chat_id
usage_ledger_id
skapad_at
updated_at
revoked_at

I en större portal lägger du till fält för förbetalt saldo, valuta, skatteregion, fakturakund-ID, supportnivå, missbruksstatus och tillfälliga åsidosättanden.

Exempel på kundpost

{
  "partner_id": "partner_123",
  "customer_id": "cust_acme",
  "workspace_id": "ws_prod",
  "plan_id": "growth_api",
  "billing_status": "aktiv",
  "spend_limit": {
    "period": "månad",
    "hard_cap_usd": 500,
    "alert_thresholds": [0.5, 0.8, 0.95]
  },
  "rate_limit": {
    "requests_per_minute": 120,
    "tokens_per_dag": 2000000
  },
  "allowed_models": ["snabbchatt", "reasoning-standard"],
  "telegram_chat_id": "-1001234567890",
  "usage_ledger_id": "ledger_cust_acme"
}

Rekommendation: behandla customer_id, workspace_id och api_key_id som separata begrepp. En kund kan ha flera arbetsytor, och varje arbetsyta kan behöva separata produktions-, iscensättnings- och utvecklingsnycklar. Detta gör återkallelse, felsökning och användningstillskrivning mycket enklare.

Introduktionssekvens för en ny kund

Ett tillförlitligt onboarding-flöde är tråkigt. Den bör producera samma journaler varje gång och lämna ett granskningsspår.

1. Skapa kunden: lagra juridiskt namn, faktureringskontakt, teknisk kontakt och intern ägare.
2. Skapa en arbetsyta: separera produktion från testning om kunden kommer att integrera programmatiskt.
3. Tilldela en plan: definiera inkluderade modeller, uppmärkning, faktureringskadens och supportförväntningar.
4. Ange gränser: konfigurera utgiftstak, begärandegränser, tokengränser och burst-policy.
5. Skapa API-nycklar: utfärda nycklar med omfattning för kundens miljöer.
6. Skicka integrationsinstruktioner: ange basadress, autentiseringsformat, modelllista, gränser och supportkanal.
7. Aktivera varningar: anslut Telegram eller en annan operationskanal för meddelanden om lågt saldo, nyckel, avbrott och fakturering.
8. Kör en testbegäran: verifiera autentisering, användningsregistrering, modellåtkomst och fakturamappning.

Rekommendation: gör onboarding idempotent. Om din administratörsapp försöker göra om en "skapa kund"-åtgärd ska den inte skapa dubbletter av faktureringsposter eller dubbletter av API-nycklar. Använd externa ID:n och idempotensnycklar för att klara samtal.

Budgetkontroll vid begäran om tid

Den viktigaste tillämpningen sker innan begäran når en uppströmsmodell. Din gateway bör inte upptäcka att en kund är över budget först efter att leverantören redan har debiterat dig.

Använd denna preflight-sekvens:

1. Autentisera nedströms API-nyckeln.
2. Lös partner_id, customer_id och workspace_id.
3. Kontrollera om nyckeln är aktiv och inte återkallad.
4. Kontrollera faktureringsstatus: aktiv, provperiod, förbetald, pausad, försenad eller avstängd.
5. Kontrollera det fasta utgiftstaket för den aktuella faktureringsperioden.
6. Kontrollera hastighetsgränser, som förfrågningar per minut och tokens per dag.
7. Kontrollera om den begärda modellen är tillåten för kundens plan.
8. Uppskatta högsta möjliga kostnad från modell, max tokens och begärandeparametrar.
9. Dirigera begäran endast om policyn godkänns.

if key.revoked:
    reject(401, "API-nyckel återkallad")
om customer.billing_status i ["pausad", "avstängd", "förfallen"]:
    avvisa(402, "Faktureringsstatus tillåter inte användning")
if requested_model inte i customer.allowed_models:
    reject(403, "Modell inte aktiverad för denna arbetsyta")
if current_period_spend + estimated_max_cost > customer.hard_cap:
    reject(402, "Utgiftsgränsen har överskridits")
if rate_limit_exceeded(customer_id, requested_model):
    avvisa(429, "Taxegränsen har överskridits")
route_request()

Fakta: OWASP API Security Top 10 2023 kallar trasiga objektauktorisering, trasig autentisering och obegränsad resursförbrukning som stora API-risker. Dessa mappar direkt till återförsäljarportaler: en hyresgäst får inte läsa en annan hyresgästs data, nycklar får inte gå att förbigå och en kund får inte kunna skapa obegränsade leverantörsutgifter.

Avvägning: strikta hårda tak skyddar din marginal, men de kan avbryta legitima toppar. En bra kompromiss är ett temporärt åsidosättande arbetsflöde med en utgångstid, godkännare, orsak och granskningsloggpost.

Användningsreskontra som källan till sanningen

För åtkomstkontroll i realtid, spara din egen användningsreskontra. Externa faktureringsverktyg är utmärkta för fakturering, men de är vanligtvis inte rätt ställe att fatta beslut på millisekundsnivå.

En användningshändelse bör fånga tillräckligt med detaljer för att stämma av leverantörsfakturor, förklara kundfakturor och felsöka tvister:

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

Spela in misslyckade förfrågningar också, men särskilj fel som är fakturerbara från misslyckanden som inte är det. Leverantörstimeout, valideringsfel, kundavbokningar, återförsök och säkerhetsblockeringar kan ha olika redovisningsresultat beroende på när de inträffar.

Rekommendation: skriv en väntande redovisningshändelse när begäran har accepterats och slutför den sedan när tokenanvändning och kostnad är känd. Detta gör att du kan reservera budget innan routing och sedan korrigera det slutliga beloppet efter slutförandet.

Avstämningsmönster

1. Lagra händelser på begäran-nivå i den interna reskontran.
2. Aggregerad användning efter kund, modell och faktureringsperiod.
3. Jämför interna summor med uppströmsleverantörsfakturor eller användningsexporter.
4. Undersök väsentliga skillnader innan du utfärdar fakturor.
5. Synkronisera sammanfattad fakturerbar användning med faktureringssystemet.

Avvägning: Synkronisering av sammanfattad användning minskar volymen och komplexiteten för faktureringshändelser, men det kan göra kundfakturor mindre detaljerade. Om kunder behöver rapportering på modell- eller projektnivå, bevara dessa dimensioner i din faktureringssynkronisering eller kundöversikt.

Faktureringssynkronisering med användningsbaserade mätare

Användningsbaserade faktureringssystem följer vanligtvis ett mönster: definiera produkter och priser, ta in användningshändelser, aggregera dem över en faktureringsperiod, generera fakturor och övervaka fel. Stripe Billing, till exempel, stöder mätarhändelser med ett händelsenamn, kundidentifierare, numeriskt värde, valfri tidsstämpel, valfri idempotensidentifierare och valfria dimensioner.

För AI API-fakturering är vanliga mätarval:

• Tokentotal: användbart när prissättningen är nära kopplad till in- och utmatningstoken.
• Antal begäranden: användbart för enkla planer eller API-anrop med låg token.
• Modellspecifika enheter: användbart när premiummodeller har olika marginaler.
• Säten eller aktiva arbetsytor: användbart för hybridplaner för SaaS-plus-användning.

Fakta: Stripe-mätare stöder aggregeringsformler som summa, count och last. Dessa mappar till tokensummor, antal begäranden och tillståndsliknande värden som platser eller aktiva gränser.

En daglig faktureringssynkronisering kan skapa mätarhändelser som detta:

{
  "event_name": "ai_tokens_used",
  "customer": "stripe_customer_456",
  "värde": 2270000,
  "timestamp": "2026-08-02T23:59:00Z",
  "idempotency_key": "cust_acme_2026-08-02_tokens",
  "dimensioner": {
    "plan": "tillväxt_api",
    "model_family": "standard"
  }
}

Rekommendation: håll den interna reskontran mer detaljerad än fakturan. Du kan fakturera totalbelopp för dagliga token samtidigt som du fortfarande behåller uppgifter på begäran-nivå för support, bedrägerigranskning, justering av räntegränser och marginalanalys.

Telegramoperationer utan att göra Telegram till registreringssystemet

Telegram är användbart för snabba operatörsarbetsflöden: supportteam märker redan meddelanden, bots kan skicka varningar och kunder kan få onboarding-instruktioner utan att logga in på en instrumentpanel. Men Telegram bör inte vara det enda revisionsspåret för fakturerings-, säkerhets- eller supportbeslut.

Bra Telegram-arbetsflöden inkluderar:

• Varningar om lågt saldo eller höga utgifter vid 50 %, 80 % och 95 % av ett tak.
• Meddelanden om nya kunder med dokumentationslänkar och maskerade nyckelnamn.
• Meddelanden om API-nyckelrotation före och efter rotation.
• Varningar om leverantörsavbrott eller försämrad modell.
• Eskalering av mänsklig support när en kund träffar upprepade 401-, 402-, 403- eller 429-fel.

Fakta: Telegram Bot API-anrop görs över HTTPS till bot-token-slutpunkter, och Telegram-webhooks kan inkludera en hemlig token-header för att verifiera webhook-ursprunget.

Rekommendation: lagra Telegram-chatt-ID:n som hyresgästmetadata, men exponera dem inte över kunder. Logga varje botutlöst administrativ åtgärd i din interna revisionslogg med aktör, tidsstämpel, kund, gammalt värde, nytt värde och anledning.

Checklista för säkerhet och isolering

Innan du säljer åtkomst, testa hyresgästisolering som om en kund aktivt försöker överskrida gränser.

• Kund A kan inte se kund B API-nycklar.
• Kund A kan inte se kund B-användning, fakturor, gränser, Telegram-chatt-ID eller faktureringsstatus.
• En återkallad nyckel misslyckas omedelbart på alla sökvägar för begäran.
• En faktureringspausad kund kan inte fortsätta spendera genom cachade sessioner eller gamla nycklar.
• En kund kan inte begära modeller utanför den tilldelade planen.
• Taxegränser gäller per kund och arbetsyta, inte bara efter global IP-adress.
• Webhook-hanterare verifierar signaturer eller hemliga rubriker där det stöds.
• All provisionering, gränsändringar, nyckelrotationer och åsidosättningar av fakturering skapar granskningsloggposter.
• Försök igen logik använder idempotensnycklar så att dubbla förfrågningar inte dubbelfakturerar kunder.
• Supportverktyg döljer hemligheter och begränsar vem som kan avslöja eller rotera nycklar.

Prognos: återförsäljarportaler kommer i allt högre grad att konkurrera om styrning och faktureringstydlighet, inte bara om tillgång till många modeller. Kunder förväntar sig användning per projekt, tydliga fakturor, snabb nyckelrotation och hårda utgifter som standardfunktioner.

Nyckel avvägningar att avgöra tidigt

Förbetalt kontra efterbetalt

Förbetalda saldon minskar kreditrisken och gör svåra avgränsningar enkla, men kunderna kan ogilla avbrott. Efterskottsbetald fakturering är smidigare för etablerade kunder, men det kräver kreditupplysningar, krav på arbetsflöden och starkare avvikelsedetektering.

Ett blandat pris jämfört med modellspecifik prissättning

Ett blandat pris är lättare att förklara. Modellspecifik prissättning skyddar marginalerna och uppmuntrar till ett effektivt modellval. Om du erbjuder många modeller, publicera en enkel kundinriktad modellkatalog och dölj onödig leverantörsspecifik komplexitet.

Realtidsmätning kontra försenad fakturering

Realtidsmätning möjliggör utgiftstak och förbetalda saldon. Det kräver också hållbara skrivningar, reprishantering och avstämning. Försenad fakturering är enklare, men det utsätter dig för skenande utgifter innan gränserna träder i kraft.

Telegram-först-stöd kontra instrumentpanel-först-stöd

Telegram är snabbt och bekant för många operatörer. En instrumentpanel är bättre för granskning, export, behörigheter och självbetjäning för kunder. Använd Telegram för aviseringar och godkännanden, men lagra den kanoniska posten i ditt system.

Aktiv lanseringsplan

1. Börja med hyresgästisolering: implementera kund-, arbetsyta-, nyckel-, planerings- och gränsposter innan du lägger till avancerade faktureringsfunktioner.
2. Utveckla förhandskontroll: blockera återkallade nycklar, avstängd fakturering, otillåtna modeller och överbegränsa trafik före rutt.
3. Skapa användningsreskontran: registrera begärande-ID:n, antal token, kostnader, återförsäljarpriser, status, tidsstämplar och idempotensnycklar.
4. Lägg till avstämning: jämför intern användning med uppströmsleverantörssummor före fakturering.
5. Synkronisera faktureringsöversikter: skicka dagliga eller timliga aggregat till din faktureringsplattform med stabila kundmappningar och idempotensnycklar.
6. Tråda Telegram-varningar: börja med meddelanden om låg balans, avbrott, nyckelrotation och stödupptrappning.
7. Kör isoleringstester: verifiera att ingen kund kan komma åt en annan kunds nycklar, användning, gränser, fakturor eller chattmetadata.

En återförsäljarportal är inte bara ett omslag kring ett AI API. Det är ett operativt lager för autentisering, hyresgästpolicy, användningsanalys, fakturering och support. Bygg upp reskontran och gränserna först, behåll nycklar uppströms på serversidan och gör varje kundvänd nyckel återkallbar, avgränsad och hänförlig.

Relaterad läsning

• AI API kostnadskontrolltekniker
• felmedveten routing och återförsök