Creeu un portal de distribuïdors d'API d'IA: aprovisionament de llogaters, mesura d'ús, facturació i operacions de Telegram

Si empaqueteu l'accés d'IA per als clients, no els entregueu les claus del proveïdor amunt. Creeu una capa de distribuïdor que emeti claus d'abast del client, faci complir els límits dels inquilins abans de cada sol·licitud, registre l'ús al vostre propi llibre major i sincronitzi els totals facturables amb el vostre sistema de facturació.

Aquesta guia descriu un model operatiu pràctic per a una API d'IA per a agències, consultors i creadors de SaaS. No és un estudi de cas de client. És una arquitectura de referència que podeu adaptar tant si feu servir una API de partner, una passarel·la interna o un servidor intermediari personalitzat davant de diversos proveïdors de models.

L'arquitectura del portal del distribuïdor

Un portal de distribuïdor segur separa quatre responsabilitats:

• Administració de partners: la vostra aplicació interna per crear clients, plans, claus, límits i fluxos de treball de suport.
• Execució de la sol·licitud: el camí de la passarel·la que autentica les claus del client, comprova la política, encamina les sol·licituds i bloqueja el trànsit que supera els límits.
• Comptabilitat d'ús: un llibre major durador que registra l'ús a nivell de sol·licitud i les entrades de preus.
• Facturació i operacions: sincronització de factures programada, alertes, avisos de rotació de claus i escalada de suport.

Un flux típic té aquest aspecte:

Aplicació d'administració de socis
  → API del soci
    → registres de clients/espai de treball
    → claus API d'abast del client
    → Pla, model, pressupost i límits de tarifes
    → sol·licitar passarel·la
    → llibre de registre d'ús
    → sincronització de facturació
    → Bot de notificació de Telegram

Fet: OpenAI recomana no compartir claus d'API basades en l'usuari per a la col·laboració i, en canvi, utilitzar claus basades en projectes, membres assignats i claus diferents amb límits de tarifa i controls de despesa aïllats. Les condicions dels serveis d'OpenAI també prohibeixen comprar, vendre o transferir claus de l'API a o des d'un tercer. Aquests fets donen suport a un disseny de distribuïdor en què les credencials avançades es mantenen al costat del servidor i els clients reben les vostres pròpies claus aigües avall.

Recomanació: emet una clau posterior per client, projecte o entorn. No reutilitzeu una clau de client en diversos clients finals. No exposeu les credencials del proveïdor a la documentació, el codi del navegador, les aplicacions mòbils, els registres o els missatges d'assistència al client.

Model de dades d'inquilí

El model d'inquilí hauria de fer explícit l'aïllament. Com a mínim, deseu aquests camps:

partner_id
client_id
workspace_id
api_key_id
pla_id
estat_facturació
límit_despesa
rate_limit
models_permesos
telegram_chat_id
usage_ledger_id
creat_a
actualitzat_a
revocat_at

En un portal més gran, afegiu camps per a saldo de prepagament, moneda, regió fiscal, identificador de client de factura, nivell d'assistència, estat d'abús i substitucions temporals.

Exemple de registre de client

{
  "partner_id": "partner_123",
  "customer_id": "cust_acme",
  "workspace_id": "ws_prod",
  "plan_id": "growth_api",
  "billing_status": "actiu",
  "límit_despesa": {
    "període": "mes",
    "hard_cap_usd": 500,
    "alert_thresholds": [0,5, 0,8, 0,95]
  },
  "rate_limit": {
    "requests_per_minute": 120,
    "fitxes_per_dia": 2000000
  },
  "allowed_models": ["xat ràpid", "estàndard de raonament"],
  "telegram_chat_id": "-1001234567890",
  "usage_ledger_id": "ledger_cust_acme"
}

Recomanació: tracteu customer_id, workspace_id i api_key_id com a conceptes separats. Un client pot tenir diversos espais de treball i cada espai de treball pot necessitar claus de producció, realització i desenvolupament independents. Això fa que la revocació, la depuració i l'atribució d'ús sigui molt més fàcil.

Seqüència d'incorporació per a un client nou

Un flux d'incorporació fiable és avorrit per disseny. Hauria de produir els mateixos registres cada vegada i deixar un rastre d'auditoria.

1. Creeu el client: emmagatzema el nom legal, el contacte de facturació, el contacte tècnic i el propietari intern.
2. Creeu un espai de treball: separeu la producció de les proves si el client s'integrarà de manera programàtica.
3. Assigna un pla: defineix els models inclosos, el marcatge, la cadència de facturació i les expectatives de suport.
4. Estableix límits: configureu límits de despesa, límits de sol·licituds, límits de testimonis i política d'explosió.
5. Crear claus d'API: emet claus amb àmbit per als entorns del client.
6. Enviar instruccions d'integració: proporcioneu l'URL base, el format d'autenticació, la llista de models, els límits i el canal d'assistència.
7. Activa les alertes: connecteu Telegram o un altre canal d'operacions per a avisos de saldo baix, clau, interrupció i facturació.
8. Executeu una sol·licitud de prova: verifiqueu l'autenticació, el registre d'ús, l'accés al model i el mapeig de factures.

Recomanació: fes que la incorporació sigui idempotent. Si la vostra aplicació d'administració torna a provar una operació de "crear client", no hauria de crear registres de facturació duplicats ni claus API duplicades. Utilitzeu identificadors externs i claus d'idempotència per subministrar trucades.

Control del pressupost en el moment de la sol·licitud

L'aplicació més important es produeix abans que la sol·licitud arribi a un model amunt. La vostra passarel·la no hauria de descobrir que un client supera el pressupost només després que el proveïdor ja us hagi cobrat.

Utilitzeu aquesta seqüència de comprovació prèvia:

1. Autentiqueu la clau de l'API descendent.
2. Resol partner_id, customer_id i workspace_id.
3. Comproveu si la clau està activa i no revocada.
4. Comproveu l'estat de facturació: actiu, de prova, prepagament, en pausa, vençut o suspès.
5. Comproveu el límit de despesa dura per al període de facturació actual.
6. Comproveu els límits de tarifes, com ara sol·licituds per minut i fitxes per dia.
7. Comproveu si el model sol·licitat està permès per al pla del client.
8. Estimeu el cost màxim possible a partir del model, les fitxes màximes i els paràmetres de la sol·licitud.
9. Envia la sol·licitud només si la política s'aprova.

si key.revoked:
    reject(401, "clau API revocada")
si customer.billing_status a ["paused", "suspended", "darrer"]:
    reject(402, "L'estat de facturació no permet l'ús")
si requested_model no és a customer.allowed_models:
    reject(403, "Model no habilitat per a aquest espai de treball")
si current_period_spend + estimated_max_cost > customer.hard_cap:
    rebutjar(402, "S'ha superat el límit de despesa")
si rate_limit_exceeded(customer_id, requested_model):
    rebutjar(429, "S'ha superat el límit de tarifa")
route_request()

Fet: OWASP API Security Top 10 2023 indica l'autorització d'objectes trencats, l'autenticació trencada i el consum de recursos sense restriccions com a principals riscos de l'API. S'assignen directament als portals de distribuïdors: un inquilí no ha de llegir les dades d'un altre inquilí, les claus no es poden ometre i un client no ha de poder crear despeses il·limitades del proveïdor.

Compartiment: els límits estrictes protegeixen el vostre marge, però poden interrompre els pics legítims. Un bon compromís és un flux de treball d'anul·lació temporal amb una data de caducitat, un aprovador, un motiu i una entrada de registre d'auditoria.

Feu servir el llibre major com a font de la veritat

Per al control d'accés en temps real, manteniu el vostre propi registre d'ús. Les eines de facturació externes són excel·lents per a la facturació, però normalment no són el lloc adequat per prendre decisions d'autorització o denegació de mil·lisegons.

Un esdeveniment d'ús hauria de captar prou detalls per conciliar les factures dels proveïdors, explicar les factures dels clients i depurar disputes:

{
  "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": "estàndard de raonament",
  "input_tokens": 1850,
  "output_tokens": 420,
  "cached_tokens": 1200,
  "cost_proveïdor": 0,0142,
  "preu_revendedor": 0,0230,
  "currency": "USD",
  "timestamp": "2026-08-02T10:15:30Z",
  "status": "reeixit"
}

Enregistreu també les sol·licituds fallides, però distingiu els errors que es poden facturar dels que no ho són. Els temps d'espera del proveïdor, els errors de validació, les cancel·lacions de clients, els reintents i els bloquejos de seguretat poden tenir resultats comptables diferents segons quan es produeixin.

Recomanació: escriviu un esdeveniment del llibre major pendent quan s'accepta la sol·licitud i, a continuació, finalitzeu-lo quan es conegui l'ús i el cost del testimoni. Això us permet reservar pressupost abans d'enrutar i, després, corregir l'import final un cop finalitzat.

Patró de conciliació

1. Emmagatzema els esdeveniments a nivell de sol·licitud al llibre major intern.
2. Ús agregat per client, model i període de facturació.
3. Compareu els totals interns amb les factures dels proveïdors avançats o les exportacions d'ús.
4. Investigueu les diferències materials abans d'emetre factures.
5. Sincronitza l'ús facturable resumit amb el sistema de facturació.

Compartiment: la sincronització de l'ús resumit redueix el volum i la complexitat dels esdeveniments de facturació, però pot fer que les factures dels clients siguin menys detallades. Si els clients necessiten informes a nivell de model o de projecte, conserveu aquestes dimensions a la vostra sincronització de facturació o al tauler de control del client.

Sincronització de la facturació amb comptadors basats en l'ús

Els sistemes de facturació basats en l'ús generalment segueixen un patró: defineixen productes i preus, ingereixen esdeveniments d'ús, agreguen-los durant un període de facturació, generen factures i supervisen els errors. Stripe Billing, per exemple, admet esdeveniments de comptador amb un nom d'esdeveniment, un identificador de client, un valor numèric, una marca de temps opcional, un identificador d'idempotència opcional i dimensions opcionals.

Per a la facturació de l'API AI, les opcions habituals de comptador són:

• Total de testimonis: útil quan el preu està estretament lligat als testimonis d'entrada i sortida.
• Recompte de sol·licituds: útil per a plans senzills o trucades a l'API de testimoni baix.
• Unitats específiques del model: útil quan els models premium tenen marges diferents.
• Seients o espais de treball actius: útil per als plans d'ús híbrids de SaaS-plus.

Fet: els mesuradors de ratlles admeten fórmules d'agregació com ara la suma, el recompte i el darrer. Aquests es mapegen amb totals de testimonis, recomptes de sol·licituds i valors semblants a l'estat, com ara seients o límits actius.

Una sincronització de facturació diària pot crear esdeveniments de comptador com aquest:

{
  "event_name": "ai_tokens_used",
  "client": "stripe_customer_456",
  "valor": 2270000,
  "timestamp": "2026-08-02T23:59:00Z",
  "idempotency_key": "cust_acme_2026-08-02_tokens",
  "dimensions": {
    "plan": "api_creixement",
    "model_family": "estàndard"
  }
}

Recomanació: mantenir el llibre major intern més granular que la factura. Podeu facturar els totals de testimonis diaris tot conservant els registres a nivell de sol·licitud per a l'assistència, la revisió del frau, l'ajustament del límit de tarifa i l'anàlisi del marge.

Operacions de Telegram sense fer de Telegram el sistema de registre

Telegram és útil per als fluxos de treball ràpids dels operadors: els equips d'assistència ja noten missatges, els robots poden enviar alertes i els clients poden rebre instruccions d'incorporació sense iniciar sessió en un tauler. Però Telegram no hauria de ser l'únic rastre d'auditoria per a decisions de facturació, seguretat o suport.

Els bons fluxos de treball de Telegram inclouen:

• Alertes de baix saldo o despesa alta al 50%, 80% i 95% d'un límit.
• Missatges d'incorporació de clients nous amb enllaços de documentació i noms de claus emmascarats.
• Avisos de rotació de claus API abans i després de la rotació.
• Alertes d'interrupció del proveïdor o de model degradat.
• Escalada d'assistència humana quan un client arriba a errors repetits 401, 402, 403 o 429.

Fet: les trucades de l'API de Telegram Bot es fan mitjançant HTTPS a punts finals de bot-token i els webhooks de Telegram poden incloure una capçalera secreta de testimoni per ajudar a verificar l'origen del webhook.

Recomanació: emmagatzemeu els ID de xat de Telegram com a metadades d'inquilí, però no els exposeu als clients. Registreu cada acció administrativa activada per bot al vostre registre d'auditoria interna amb actor, marca de temps, client, valor antic, valor nou i motiu.

Llista de verificació de seguretat i aïllament

Abans de vendre l'accés, proveu l'aïllament dels inquilins com si un client intentés traspassar els límits.

• El client A no pot veure les claus de l'API del client B.
• El client A no pot veure l'ús, les factures, els límits, els ID de xat de Telegram o l'estat de facturació del client B.
• Una clau revocada falla immediatament en tots els camins de sol·licitud.
• Un client en pausa amb la facturació no pot continuar gastant mitjançant sessions emmagatzemades a la memòria cau o claus antigues.
• Un client no pot sol·licitar models fora del pla assignat.
• S'apliquen límits de tarifes per client i espai de treball, no només per adreça IP global.
• Els gestors de webhook verifiquen les signatures o les capçaleres secretes quan s'admeten.
• Tots els aprovisionaments, els canvis de límits, les rotacions de claus i les anul·lacions de facturació creen entrades de registre d'auditoria.
• La lògica de reintentar utilitza claus d'idempotència, de manera que les sol·licituds duplicades no facturen els clients per doble.
• Les eines de suport emmascaren secrets i restringeixen qui pot revelar o girar les claus.

Predicció: els portals de distribuïdors competiran cada cop més pel que fa a la governança i la claredat de facturació, no només en l'accés a molts models. Els clients esperaran l'ús per projecte, les factures clares, la rotació ràpida de tecles i els controls de despesa dura com a funcions estàndard.

Compartiments clau per decidir aviat

Prepagament versus postpagament

Els saldos de prepagament redueixen el risc de crèdit i faciliten els talls durs, però és possible que els clients no els agradin les interrupcions. La facturació de postpagament és més fluida per als clients establerts, però requereix comprovacions de crèdit, fluxos de treball de sol·licitud i una detecció d'anomalies més forta.

Un preu combinat versus un preu específic del model

Un preu combinat és més fàcil d'explicar. El preu específic del model protegeix els marges i fomenta la selecció eficient del model. Si ofereixeu molts models, publiqueu un catàleg de models senzill orientat al client i amagueu la complexitat específica del proveïdor innecessària.

Mesuració en temps real versus facturació retardada

La mesura en temps real permet límits de despesa i saldos de prepagament. També requereix escriptures duradores, gestió de reproduccions i reconciliació. La facturació endarrerida és més senzilla, però us exposa a una despesa descontrolada abans que els límits entrin en vigor.

Assistència de telegram primer versus assistència de tauler de control

Telegram és ràpid i familiar per a molts operadors. Un tauler és millor per a l'auditabilitat, les exportacions, els permisos i l'autoservei del client. Utilitzeu Telegram per a notificacions i aprovacions, però emmagatzemeu el registre canònic al vostre sistema.

Pla de llançament accionable

1. Comenceu amb l'aïllament dels inquilins: implementeu registres de clients, espais de treball, claus, plans i límits abans d'afegir funcions de facturació avançades.
2. Crear l'aplicació del control previ: bloqueja les claus revocades, la facturació suspesa, els models no permesos i sobrelimita el trànsit abans d'enrutar.
3. Creeu el llibre de registre d'ús: registreu els identificadors de sol·licituds, el recompte de testimonis, els costos, els preus dels distribuïdors, els estats, les marques de temps i les claus d'idempotència.
4. Afegiu una conciliació: compareu l'ús intern amb els totals dels proveïdors aigües amunt abans de facturar.
5. Sincronitza els resums de facturació: envieu agregats diaris o per hores a la vostra plataforma de facturació amb mapes de clients estables i claus d'idempotència.
6. Alertes de Telegram per cable: comenceu amb missatges de balanç baix, interrupció, rotació de tecles i missatges d'escalada de suport.
7. Executa proves d'aïllament: verifiqueu que cap client pugui accedir a les claus, l'ús, els límits, les factures o les metadades del xat d'un altre client.

Un portal de distribuïdor no és només un embolcall al voltant d'una API d'IA. És una capa operativa per a l'autenticació, la política de llogaters, l'anàlisi d'ús, la facturació i el suport. Creeu primer el llibre major i els límits, mantingueu les claus amunt al costat del servidor i feu que totes les claus orientades al client siguin revocables, amb abast i atribuïbles.

Lectura relacionada

• Tècniques de control de costos de l'API AI
• enrutament i reintents conscients dels errors