Autentisering

Model Gate produktionsnycklar börjar med mg_live_. Samma nyckel fungerar för OpenAI-kompatibla och Anthropic-kompatibla förfrågningar.

OpenAI-kompatibel rubrik

Authorization: Bearer mg_live_...
Content-Type: application/json

Använd detta formulär för /v1/chat/completions, /v1/responses, /v1/embeddings, /v1/images/generations, /v1/models, och /v1/balance.

Antropisk-kompatibel rubrik

x-api-key: mg_live_...
anthropic-version: 2023-06-01
content-type: application/json

Använd detta formulär för /v1/messages och /v1/messages/count_tokens. Bärarautentisering accepteras också.

Begär exempel

curl https://api.model-gate.com/v1/models \
  -H "Authorization: Bearer mg_live_..."

Exempel på svar

{
  "object": "list",
  "data": []
}

Oautentiserade slutpunkter

Endast service-hälsoslutpunkter är oautentiserade:

GET /health
GET /health/live
GET /health/ready

Interaktiva webbläsarsessioner

Model Gate-kontopanelen använder en webbläsarsession på serversidan som är skild från Model API-nycklar. Som standard upphör en autentiserad webbläsarsession efter 12 timmar utan autentiserad aktivitet eller efter 7 dagar totalt, beroende på vad som kommer först. Webbläsarcookien i sig förblir en sessionscookie, så om du stänger webbläsaren kan den avslutas tidigare beroende på webbläsarens beteende.

När en kontopanelsida fortfarande är öppen efter att autentiseringen löper ut returnerar AJAX-åtgärder HTTP 401 JSON med kod authentication_required och panelen visar en Sessionen har löpt ut prompt istället för att behandla inloggningssidan som JSON. En inaktuell sida/CSRF-token returnerar HTTP 419 JSON med kod csrf_expired och ber om en uppdatering av sidan. Misslyckade mutationer, inklusive betalningsinitiering, spelas aldrig upp automatiskt efter inloggning eller uppdatering.

Konto- och IP-säkerhet

Den autentiserade profilen kan aktivera TOTP-tvåfaktorsautentisering med WinAuth eller annan kompatibel autentisering. Företagsorganisationer kan kräva TOTP för varje medlem; detta krav är aktiverat som standard för företagsorganisationer. En avslutad andrafaktorutmaning registreras i den aktuella webbläsarsessionen. Känsliga kontoåtgärder som att skapa/avslöja/rotera autentiseringsuppgifter, ändra säkerhetspolicy och återskapa säkerhetshemligheter kräver ett nyligen genomfört andrafaktorsbevis när TOTP är aktiverat; standardfönstret för bekräftelse är 60 minuter (konfigureras av TWO_FACTOR_STEP_UP_TTL_SECONDS). Detta ändrar inte autentiseringskoden på 30 sekunder.

Om du aktiverar TOTP skapas tio engångsåterställningskoder. Deras fullständiga värden visas endast när de genereras; Model Gate lagrar endast hash och förbrukar atomärt en kod efter användning. Återskapande av återställningskoder ogiltigförklarar äldre oanvända koder. TOTP-registrering kräver det aktuella lösenordet när kontot har ett, eller en ny primär OAuth/Telegram-autentisering för lösenordslösa konton. Lösenordsändringar, TOTP-aktivering/avaktivering/återställning och ändringar av inloggningssäkerhetspolicy återkallar inaktuella webbläsarsessioner. Administratörer och företagsägare/adminanvändare kan återställa en hanterad användares TOTP när återställning krävs; den återställningen loggar ut målets webbläsarsessioner men återkallar inte Model API-uppgifter.

Profilen presenterar Autentiseringsapp (TOTP) och IP-godkännandelistor som separata säkerhetskontroller. Initial registrering av autentisering öppnar en modal och slutför installationen/bekräftelsen med AJAX samtidigt som den normala POST-backupen på serversidan behålls. Inloggnings-/API-tillståndslistor redigeras i en separat modal och sparas med AJAX efter samma senaste 2FA-step-up-policy.

Profilen stöder även separata inloggnings- och API IP-godkännandelistor. Reglerna är exakta IPv4/IPv6-adresser eller CIDR-prefix. En tom lista betyder ingen begränsning. Företagsägare/administratörer kan dessutom definiera organisationsomfattande inloggnings- och API-godkännandelistor. När både personliga och organisations-API-regler finns måste förfrågningskällan matcha båda. En begäran som avvisats av en API IP-policy returnerar HTTP 403 med kod ip_not_allowed där kompatibilitetssvarsformatet visar en felkod.

För företagsuppgifter förblir företagsägaren faktureringsägare medan varje autentiseringsuppgifter registrerar en autentiseringsanvändare (huvudman). Huvudmannens aktiva status, personliga API IP-godkännandelista och användarens RPM/samtidighetsgränser gäller för den nyckeln; företagets balans/prissättning och organisationens API-IP-policy förblir företagsomfattande. Anställdas autentiseringsuppgifter måste tilldelas en aktiv grupp och kräver en körbar Business-tillstånd (admin eller developer, med organisationens ägare/administratörsbefogenhet också accepterad). billing och viewer gruppbehörigheter kör inte Model API-trafik.

En gruppadministratör kan hantera nycklar i den gruppen, men kan inte avslöja eller rotera en hemlighet som utfärdats till en annan behörighetsansvarig; rektorn själv och organisationens ägare/administratör kan få åtkomst till den legitimationshemligheten. Om en ägare-huvudmanshemlighet delades med anställda före 9.6.2, rotera den och utfärda dedikerade anställd-huvudmannens autentiseringsuppgifter för att erhålla tillförlitligt beteende för återkallande/IP-uppförande per anställd.

TOTP skyddar interaktiv inloggning och känsliga mänskliga kontoåtgärder. Lösenord, OAuth och Telegram-inloggning använder alla samma andrafaktorspolicy. Återställningskoder kan användas en gång i stället för TOTP för inloggning eller steg-up. Känsliga Telegram-kommandon kräver en andra faktor när TOTP är registrerad, och inlämnade koder redigeras från varaktig Telegram-uppdatering/konversationslagring. Modell API-förfrågningar gör det inte fråga efter eller validera en TOTP-kod: en redan utfärdad nyckel är auktoriserad av nyckeltillståndet, autentiseringshuvudstatus/behörigheter, effektiva IP-godkännandelistor och körtid/faktureringsgränser.

• Lagra nycklar i miljövariabler eller en hemlig hanterare.
• Ge aldrig en nyckel till Git.
• Använd en separat nyckel för varje projekt eller extern användare.
• Frys eller rotera en komprometterad nyckel omedelbart.
• Modellens API-nyckelhemligheter visas endast vid skapande eller rotation.
• Partner API bärartokens visas också endast vid generering/rotation och lagras endast hash av Model Gate.
• Återuppringningssigneringshemligheter visas endast vid generering/rotation och krypteras i vila; lagra din kopia i en hemlig manager.
• Om du aktiverar en API IP-godkännandelista, inkludera alla utgående NAT/utgångsadresser som kan anropa Model Gate.

Delade projektnycklar i Playground

Affärsprojektutvecklare och administratörer kan välja projektnycklar i Playground även när en annan medlem skapat nyckeln. Den tillfälliga webbläsaruppgifterna använder den inloggade medarbetaren som sin exekveringsidentitet: deras nuvarande grupptillstånd, personliga API-IP-policy och gränser per användare gäller. Nyckel-/gruppanvändning och faktisk fakturering förblir kopplade till företaget. Detta avslöjar inte en annan medlems återanvändbara nyckelhemlighet eller ger en utvecklare tillgång till företagets plånbok. Webbläsarsessioner kan inte skicka uppskjutna asynkron- eller batchjobb; använd en dedikerad långlivad referens för dessa integrationer.

Läsa användningskontroller

API-nycklar och nyckelgrupper visas Användningsgräns, USD mot återställbar användning, inte livstidskostnad. Nyckel- och grupptak tillämpas båda; noll tar bara bort taket på det objektet. RPM och samtidighet är separata gränser för antal begäranden, och tillgängligt plånbokssaldo är en annan förutsättning.

Gruppägaren kan välja Återställ användning i grupper efter den vanliga säkerhetsbekräftelsen. Detta rensar endast gruppräknaren; nyckelåterställningen i en utökad API-nyckelrad rensar endast den nyckeln. Varken åtgärder återbetalar en betalning, ändrar livstidsutgifter eller tar bort förfrågningar. Återstående kvot och den senaste återställningstiden visas bredvid kontrollerna.

Värderad användning ärver prisbas och multiplikator oberoende från nyckel till grupp. Det är inte en annan plånboksladdning. Bokföring avräknas med jämna mellanrum, så förfrågningar under flygning kan passera en kvot eller sluta efter en återställning; dessa är inträdesgränser, inte en exakt reservation för framtida utgifter.