Hur man bygger ett Partner LLM API utan att exponera Raw Provider Keys

En partner API för LLM-åtkomst bör inte vara ett tunt omslag runt leverantörsnycklar. Om partners, återförsäljare eller kundapplikationer behöver delegerad åtkomst till språkmodeller behöver plattformen sitt eget kontrollplan, gateway, policylager, mätningspipeline och operativa runbooks. Annars blir fakturering på leverantörsnivå, gränser på leverantörsnivå och delade autentiseringsuppgifter de enda kontrollerna mellan en partnerintegrering och en mycket dyr incident.

Målet är okomplicerat: låt externa parter konsumera LLM-kapacitet via din plattform samtidigt som du håller uppströmsleverantörsuppgifterna privata, upprätthåller partnerspecifika rättigheter, mäter fakturerbar användning och ger partners tillräcklig insyn för att bygga pålitliga kunder.

Referensarkitektur

En praktisk partner API har två huvuddelar: ett kontrollplan och en begäran-gateway.

Kontrollplanet hanterar partnerorganisationer, applikationer, miljöer, delegerade API-nycklar, modellrättigheter, nivåer för satsgränser, utgiftstak, faktureringsvillkor, webhook-slutpunkter och revisionsposter. Det är där kommersiella och operativa regler blir maskinläsbar policy.

Begärans gateway tar emot partnertrafik, autentiserar den delegerade nyckeln, utvärderar policy, tillämpar kvot, rutter till den valda modellleverantören, registrerar användning och returnerar partnersynliga svarsmetadata. I en mogen enterprise LLM API är denna gateway också där modellrouting, återförsök, failover, innehållskontroller och observerbarhet upprätthålls konsekvent.

Den viktiga gränsen är denna: partners får bara dina plattformsutfärdade nycklar. De får aldrig råa leverantörsuppgifter. Uppströmsleverantörsnycklar stannar i din hemliga plattformsbutik och används endast av gateway- eller backend-arbetare.

Faktamönster att bygga runt

Följande är fakta som stöds av offentlig plattform och molndokumentation, inte antaganden om en implementering:

• Vissa LLM-leverantörer stöder projektomfattande nycklar, tjänstekonton, modellåtkomst på projektnivå och prisgränser på projektnivå.
• Molnvägledning för SaaS API:er för flera innehavare separerar vanligtvis policyadministration, policybeslut och policytillämpning för att minska oavsiktlig åtkomst mellan klienter.
• API gateways och SaaS-kontrollplan kan tillämpa hyresgästspecifika stryp- och kvotkontroller, inklusive hastighet, burst och kvotnivåer.
• Användningsbaserad SaaS-fakturering beror på att man samlar in hyresgästaktivitet, sammanställer den och stämmer av den mot faktureringsposter.
• Idempotensnycklar är ett dokumenterat mönster för att säkert försöka igen tillståndsändrande API förfrågningar utan att skapa dubbla biverkningar.
• Standardiserade svarsrubriker för hastighetsgränser kan hjälpa kunder att förstå gränser, återstående tillstånd, återställa timing och försök igen.

Rekommendationen är att kombinera dessa mönster till ett partnerinriktat LLM-åtkomstlager som du äger, istället för att be varje partner att integrera direkt med varje uppströmsmodellleverantör.

Steg 1: Definiera hyresgästen och identitetsmodellen

Identifiera inte partnertrafik med endast en API-nyckelsträng. En användbar partner API behöver separata identifierare eftersom fakturering, missbruksgranskning, kvotfelsökning och supportundersökningar ofta ställer olika frågor.

Skapa åtminstone identifierare för:

• Partnerorganisation: det avtalade externa företaget.
• Partnerapplikation: en specifik integrations-, produkt-, plugin- eller återförsäljarapplikation.
• Miljö: produktion, iscensättning, sandlåda eller utveckling.
• Slutkund: partnerns kund, arbetsyta, konto eller hyresgäst, när det är avtalsenligt tillåtet och tekniskt tillgängligt.
• API-nyckel: den delegerade autentiseringsinformationen som används för att autentisera förfrågningar.
• Request ID: en unik identifierare för att spåra en begäran över din gateway, leverantörssamtal, användningshändelser och supportloggar.

Den här strukturen undviker det vanliga felläget där en komprometterad eller bullrig integration bara kan beskrivas som "partner X-trafik." Det låter dig också stänga av en applikation eller miljö utan att inaktivera partnerns hela verksamhet.

Steg 2: Utfärda delegerade partnernycklar

Partnernycklar ska vara förstklassiga plattformsobjekt, inte statiska tokens i ett kalkylark. Varje nyckel bör ha metadata och policybindningar:

• Partnerorganisations-ID
• Applikations-ID
• Miljö
• Tillåtna API ytor, som chatt, inbäddningar, batch- eller bildgenerering
• Tillåtna modellalias
• Regions- eller datauppehållsbegränsningar där tillämpligt
• Rate-limit tier
• Utgiftstak eller regel för förbetalt saldo
• Skapningstid, senast använd tid, ägare och rotationsstatus

Lagra endast hashat nyckelmaterial där det är möjligt, avslöja fullständiga hemligheter endast en gång vid skapandet och stöd rotation utan driftstopp. En praktisk rotationsmodell tillåter två aktiva nycklar under ett kort övergångsfönster, med granskningsloggar som visar vilken nyckel som användes för varje begäran.

Steg 3: Separera rättigheter från routing

En partners rätt att använda en modell bör inte antydas av den routingkod som för närvarande stöds. Håll behörighetskontroller tydliga och åtskilda från valet av leverantör.

Till exempel bör en begäran om model: premium-reasoning först passera ett policybeslut:

• Får den här partnern använda modellaliaset?
• Får partnerappen använda den i den här miljön?
• Är begäran inom den tillåtna regionen eller datagränsen?
• Är avtalet aktivt och har god status?
• Är partnern inom utgifts-, kvot- och missbrukströsklar?

Först efter det beslutet bör routing välja uppströmsleverantör, leverantörsprojekt, implementering eller reservväg. Detta är viktigt eftersom ändringar av modellrutt är operativt frekventa. Ändringar av rättigheter bör vara avsiktliga och granskningsbara.

Steg 4: Publicera en stabil partner API Surface

Partners behöver stabilt beteende även när dina uppströmsleverantörer ändras. Använd dina egna modellalias och funktionsbeskrivningar istället för att exponera varje leverantörs modellnamn direkt.

Ett litet exempel:

POST /v1/chat/completions
Authorization: Bearer partner_key_...
Idempotency-Key: job_01J7...
X-Partner-Customer-Id: customer_123

{
  "model": "standard-chat",
  "messages": [
    {"role": "user", "content": "Summarize this support thread."}
  ],
  "metadata": {
    "ticket_id": "T-44821",
    "workflow": "support_summary"
  }
}

Partnern frågar efter standard-chat. Din gateway mappar som alias till den aktuella godkända leverantören och modellen, beroende på rättigheter, tillgänglighet, pris, latens, region och kvalitetsregler.

Undvik dock att dölja alla leverantörsskillnader. Om två modellalias har olika kontextfönster, stöd för strukturerad utdata, beteende för verktygsanrop, latensprofiler eller regional tillgänglighet, dokumentera dessa skillnader tydligt. Abstraktion bör förenkla integrationen, inte skapa överraskande beteende.

Steg 5: Tillämpa kvoter innan leverantörssamtal

Providergränser är användbara skyddsräcken, men tillsyn på partnernivå hör hemma på din plattform. Ett uppströms leverantörsprojekt kan betjäna många partners, eller så kan en partner ha flera ansökningar med olika kontrakt. Att enbart förlita sig på prisgränser på leverantörsnivå kan inte uttrycka dessa skillnader rent.

Tillämpa kvotkontroller innan du ringer uppströmssamtal:

• Förfrågningar per minut av partnernyckel
• Tokens per minut av partnerorganisation
• Samtidiga förfrågningar per applikation
• Daglig eller månatlig fakturerbar enhetskvot
• Förbetalt saldo eller kredittröskel
• Per-end-customer caps där så krävs

För synkrona förfrågningar, avvisa tydligt när begäran inte kan accepteras. För asynkrona och batch-arbetsbelastningar, överväg kötillträde separat från exekveringskvoten. En batchuppladdning kan accepteras, men enskilda jobb bör fortfarande mätas och stoppas när partnergränserna nås.

Steg 6: Returnera förutsägbara hastighetsgränssignaler

Ogenomskinliga 429 Too Many Requests svar skapar supportbiljetter som kan undvikas. Returnera partner-synliga kvotsignaler på framgångsrika och strypta svar.

Ett användbart svar kan inkludera:

RateLimit-Limit: 600;w=60
RateLimit-Remaining: 42
RateLimit-Reset: 17
Retry-After: 17
X-Request-Id: req_01J8...

Rekommendationer:

• Dokumentera om gränser gäller per nyckel, applikation, organisation, modell eller slutpunkt.
• Återställningstidpunkt som kunderna kan agera på.
• Använd Retry-After för begränsade svar.
• Håll felkropparna stabila och maskinläsbara.
• Exponera inte uppströmsleverantörernas interna delar om inte partner behöver dem för att felsöka beteende.

Detta gör partnerklienter enklare att bygga och minskar stormar vid försök igen under trafiktoppar.

Steg 7: Använd idempotens för fakturerbart arbete

Alla slutpunkter som skapar statligt eller fakturerbart arbete bör stödja idempotensnycklar. Detta är särskilt viktigt för jobb som genererar async, batch-inlämningar, kreditköp, webhook-utlösta återförsök och långvariga uppgifter.

Implementeringsregeln är enkel: när en partner upprepar samma begäran med samma idempotensnyckel i retentionsfönstret, returnera det ursprungliga resultatet istället för att skapa dubblettarbete.

Gör kantfallen explicit:

• Hur länge idempotensposter bevaras
• Vilken slutpunkt och partnernyckel som idempotensnyckeln omfattar
• Vad händer om samma nyckel återanvänds med olika begärandeparametrar
• Om misslyckade förfrågningar cachelagras
• Hur idempotens gäller för delvis slutförda batchjobb

För fakturerbart LLM-arbete, lagra tillräckligt med begärande fingeravtrycksdata för att upptäcka parameterfel utan att behålla onödigt känsligt nyttolastinnehåll.

Steg 8: Sänd ut oföränderliga användningshändelser

Behandla inte leverantörsfakturor som sanningens källa för partnerfakturering. Leverantörsfakturor känner vanligtvis inte till dina partnerkontrakt, uppmärkningsregler, återförsäljarnivåer, slutkunds-ID eller tvistarbetsflöde. Sänd istället ut en oföränderlig användningshändelse när varje begäran når ett terminaltillstånd.

En användningshändelse bör innehålla:

• Partnerorganisations-ID
• Applikations-ID och miljö
• API nyckel-ID, inte rånyckeln
• Slutkunds-ID om tillhandahållet och tillåtet
• Begär-ID och leverantörs-korrelations-ID
• Modellalias och uppströmsleverantörsmodell
• Indatatoken, utdatatoken, cachade tokens eller andra fakturerbara enheter
• Providerkostnadsbas när tillgänglig
• Partnerfaktureringsenhet, märkning, kredituttag eller kontraktsränta
• Status, felklass, latens och antal försök
• Tidsstämpel och schemaversion

Dessa händelser matar partnerinstrumentpaneler, faktureringsexport, avvikelsedetektering, kvoträknare och avstämning. Behåll händelseströmmen endast som tillägg. Korrigeringar bör vara justeringshändelser, inte tysta redigeringar.

Steg 9: Avstämning dagligen

Mätning är bara användbar om den stämmer. Bygg upp en daglig process som jämför dina användningshändelser med uppströmsleverantörsanvändning, leverantörsfakturor, kreditsaldon och partnerinriktade faktureringsuppgifter.

Avstämningsprocessen bör identifiera:

• Förfrågningar accepterade av din gateway men saknade terminalanvändningshändelser
• Användning av leverantör som inte kan mappas till en partnerförfrågan
• Tokenantal skillnader mellan leverantörsrapporter och gatewayposter
• Återförsök som fakturerades felaktigt
• Manuella krediter, återbetalningar och faktureringskorrigeringar
• Partner som närmar sig utgifter, förutbetalda utmattning eller ovanlig tillväxt

Det är också här som ekonomi, support och teknik behöver samma ID. Om instrumentpanelen, fakturaraden, logghändelsen och leverantörsposten inte kan kopplas samman blir tvister manuella undersökningar.

Steg 10: Bygg operativa körböcker

En partner API är en extern produktyta, så driftbeteende måste planeras innan incidenter inträffar. Skriv åtminstone runbooks för dessa situationer:

• Komprometterad partnernyckel: återkalla eller suspendera en nyckel, meddela partnern, bevara granskningsloggar och ange en rotationsväg.
• Runaway use: tillämpa nödstopp, pausa en app eller kräva godkännande för vidare användning.
• Leverantörsavbrott: misslyckas med en godkänd leverantör eller returnerar ett stabilt fel med hjälp av försök igen.
• Kvotutmattning: visar om partnern behöver vänta, uppgradera, köpa krediter eller minska trafiken.
• Webhook replay: verifiera signaturer, använd idempotens och spåra händelseleveransförsök.
• Faktureringskorrigering: skapa justeringshändelser och bevara de ursprungliga användningsposterna.

Runbooks bör definiera vem som kan vidta varje åtgärd. Att stänga av en nyckel skiljer sig från att inaktivera en partnerorganisation. Att höja en kvot skiljer sig från att ändra ett kontrakt. Nödkontroller behöver granskningsspår.

Avvägningar

En Partner API-gateway lägger till latens och operativt ansvar. Det är kostnaden för att kontrollera autentiseringsuppgifter, kvoter, routing, fakturering och synlighet på partneravtalsnivå.

Strikta kvoter skyddar marginaler och minskar missbruk, men de kan skapa onödiga misslyckanden om sprängbeteende och vägledning om försök är dåligt utformade. Ett användbart kvotsystem har både hårda gränser och dokumenterat burstbeteende.

Detaljerad mätning förbättrar faktureringstransparens och supportresultat, men det ökar skyldigheterna för lagring, integritet och avstämning. Samla in de identifierare som behövs för drift och fakturering, men undvik att lagra obearbetat meddelande och svarsinnehåll i faktureringsposter såvida det inte finns en tydlig avtals- och efterlevnadsgrund.

Modellabstraktion gör partnerintegrationer enklare, men överdriven abstraktion kan dölja materiella skillnader. Partners behöver inte känna till alla leverantörsimplementeringsdetaljer, men de behöver veta när ett modellalias ändrar kontextgränser, utdataformat, latensförväntningar eller regional tillgänglighet.

Implementeringschecklista

• Utfärda plattformsägda partnernycklar istället för att dela leverantörsuppgifter.
• Mappa varje nyckel till partner-, applikations-, miljö-, berättigande-, kvot- och faktureringsposter.
• Håll behörighets- och behörighetskontroller åtskilda från routinglogik.
• Använd stabila modellalias med dokumenterade möjligheter och begränsningar.
• Tillämpa kvotkontroller innan uppströmsleverantörssamtal.
• Rubriker för returhastighetsgräns och maskinläsbara fel.
• Kräv idempotensnycklar för slutpunkter som skapar statligt eller fakturerbart arbete.
• Skicka ut oföränderliga användningshändelser när begäran är klar.
• Avstämma användning mot leverantörsuppgifter och partnerfakturor.
• Underhåll runbooks för nyckelkompromettering, skenanvändning, leverantörsavbrott, kvotutmattning, webhook replay och faktureringskorrigering.

Aktiveringsbar slutsats

Den säkraste partnern API för LLM-åtkomst är inte en proxy som vidarebefordrar förfrågningar med dolda autentiseringsuppgifter. Det är ett delegerat åtkomstsystem med sin egen identitetsmodell, policylager, kvottillämpning, användningsmätare, avstämningsprocess och insyn mot partner.

Börja med kontrollgränserna: partnernycklar, explicita rättigheter, kontroller av kvoter före samtal, idempotenta tillståndsändrande slutpunkter och oföränderliga användningshändelser. Lägg sedan till operativ mognad: instrumentpaneler, avstämning, hastighetsgräns-semantik och incidentrunbooks. Den här arkitekturen låter partners bygga vidare på LLM-kapacitet utan att ta emot råa leverantörsnycklar, samtidigt som den ger plattformen tillräcklig kontroll för att hantera kostnader, missbruk, tillförlitlighet och faktureringstvister.

Relaterad läsning

• designing styrd API för team och partners integrationer