Naar inhoud springen
Handleidingen
Handleidingen

Snelstart

Maak standaard API-sleutels en beveiligingsregels aan en beheer ze met een RunAPI-beheerssleutel.

Platformbeheer stelt accountbeheerders in staat om standaard API-sleutels en beveiligingsrichtlijnen aan te maken, in te zien, bij te werken en in te trekken zonder voor elke wijziging het dashboard te gebruiken.

Een beheerssleutel aanmaken

Volg de Authenticatie-handleiding om u aan te melden, open vervolgens de pagina Beheerssleutels en maak een beheerssleutel aan. Bewaar hem apart van standaard applicatiesleutels. Stuur hem als bearer-token uitsluitend naar Platform Management-eindpunten.

HTTP
Authorization: Bearer YOUR_MANAGEMENT_KEY

Een standaard API-sleutel kan geen eindpunten voor sleutel- of guardrailbeheer aanroepen. Een geldige beheersleutel kan toch 403 Forbidden ontvangen wanneer de eigenaar niet langer de vereiste accountrol heeft.

Standaard API-sleutels weergeven

Gebruik GET /api/v1/keys om sleutels te inspecteren die zichtbaar zijn voor het account van de beheersleutel:

SHELL
curl "https://runapi.ai/api/v1/keys" \
  -H "Authorization: Bearer YOUR_MANAGEMENT_KEY"

Gebruik geretourneerde publieke identifiers voor latere ophaal-, bijwerk-, intrek- of guardrail-toewijzingsverzoeken. Leid nooit toegang af uit een sleutelnaam of gemaskerd token.

Een sleutel aanmaken en roteren

Maak een applicatiesleutel aan met POST /api/v1/keys. Het volledige geheim wordt alleen geretourneerd in de aanmaakreactie; sla het op in uw geheimenbeheerder voordat u die reactie verwijdert. Bij rotatie dient u een vervangend sleutel aan te maken, deze in de applicatie te implementeren, het verkeer te verifiëren en vervolgens de oude sleutel in te trekken.

SHELL
curl -X POST "https://runapi.ai/api/v1/keys" \
  -H "Authorization: Bearer YOUR_MANAGEMENT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name":"Production worker","tags":["env:production","dept:ml","project:chatbot"]}'

credit_limit_windows accepteert elke combinatie van doorlopende bestedingslimieten voor 1h, 1d en 7d. Als een geconfigureerd venster uitgeput is, retourneren aanroepen met die sleutel 429 Too Many Requests totdat het gebruik buiten het venster valt. Stuur een leeg object bij het bijwerken van een sleutel om alle doorlopende limieten te wissen.

Wanneer een aanmaakverzoek alle velden voor bestedingslimieten en guardrail_id weglaat, gebruikt de nieuwe sleutel de standaardinstellingen voor governance van de werkruimte. Expliciete limieten, voortschrijdende vensters of een guardrail vervangen die standaardkeuze. Verstuur credit_limit_cents: null om een onbeperkte ingebouwde limiet aan te maken. Een opgegeven bedrag zonder resetinterval blijft een levenslange limiet. Updates passen de standaardinstellingen van de werkruimte nooit opnieuw toe, en wijzigingen in de standaardinstellingen veranderen bestaande sleutels niet.

Sleuteltags

Aanmaken en bijwerken accepteren tags, een array met volledige key:value-strings. Antwoorden voor lijst, ophalen, aanmaken en bijwerken geven de volledige array terug. PATCH vervangt de array; weglaten van tags behoudt deze. De sleutel moet 1–32 en de waarde 1–64 tekens bevatten, met precies één dubbele punt en zonder witruimte. Maximaal 20 verschillende tags zijn toegestaan, inclusief de voorinstellingen. Ongeldige formaten of conflicterende voorinstellingen geven 422 met tagvalidatiefouten; een niet-array of niet-stringelement geeft 400.

Precies één doeltag is vereist: usage:developer of usage:service. Aanmaken via de Management API voegt usage:service toe als geen doel is opgegeven, ook bij tags: []. Aanmaken in het Dashboard en tagupdates zonder doel gebruiken usage:developer. Bestaande sleutels worden als Developer gemigreerd. De omgeving is optioneel en accepteert maximaal één van env:production, env:staging of env:dev (env:prod wordt niet geaccepteerd).

Het dashboard biedt bij het aanmaken en bewerken snelkeuzes voor doel en omgeving, plus aangepaste tags en suggesties van bewaarde standaardsleutels uit uitsluitend de huidige werkruimte. Lijsten tonen waarden en bij aanwijzen de volledige tag. Tags wijzigen het eigendom, de zichtbaarheid of de rechten van sleutels niet. Tags kunnen een sleutel koppelen aan een gedeeld tagbudget.

Verplichte tags voor leden

Werkruimtebeheerders stellen de verplichte tags van een lid in via Team, met het budgetformulier van het lid. Verplichte tags zijn hoofdlettergevoelige aangepaste tags, zoals team:growth. De naamruimten usage: en env: zijn gereserveerd. Een lid kan maximaal 19 verplichte tags hebben en elke sleutel blijft beperkt tot 20 tags in totaal.

Elke nieuwe standaardsleutel bevat automatisch de verplichte tags van de eigenaar in die werkruimte. Bij het aanmaken worden ingediende tags vóór validatie gecombineerd met de verplichte tags. Als een lid bijvoorbeeld team:growth vereist, retourneert een aanmaakverzoek via de Management API met tags: ["project:chatbot"] de tags project:chatbot, team:growth en de standaardwaarde usage:service.

Een PATCH met tags moet alle verplichte tags behouden. Het verwijderen van een verplichte tag retourneert 422 met een validatiefout die de ontbrekende tags noemt, ook als de aanroeper een beheerder is. Als tags wordt weggelaten, blijven de tags van de sleutel behouden. Leden kunnen gewone tags nog steeds toevoegen of verwijderen.

Om een verplichte tag te verwijderen, wijzigt een beheerder de configuratie van het lid in Team. Bij het opslaan worden nieuwe verplichte tags toegevoegd aan alle bestaande standaardsleutels van dat lid en ingetrokken verplichte tags verwijderd. Andere tags blijven ongewijzigd. Dit omvat uitgeschakelde en verlopen sleutels, maar geen verwijderde sleutels. Als een sleutel de uiteindelijke tagset niet kan accepteren, mislukt de volledige opslag en geeft het formulier aan welke sleutel moet worden aangepast.

Tagbudgetten gebruiken de huidige tags van elke sleutel. Het wijzigen van verplichte tags wijzigt ook de budgettoewijzing van bestaande uitgaven in de huidige periode. Het toevoegen van een verplichte tag kan het budget ervan onmiddellijk uitputten. Bestaande leden beginnen zonder verplichte tags en hun sleutels blijven ongewijzigd totdat een beheerder een configuratie opslaat.

Guardrails toepassen

Guardrails zijn herbruikbaar accountbeleid voor model-, provider- en bestedingscontroles. Beheer beleid via /api/v1/guardrails en gebruik vervolgens /api/v1/guardrail_assignments om ze te koppelen of te verwijderen. Behandel een geweigerde toewijzing als een beleids- of eigendomsfout in plaats van stil door te gaan zonder de guardrail.

Beheerfouten afhandelen

  • 401 Unauthorized betekent dat de referentie ontbreekt, ongeldig van opmaak is, ingetrokken is of niet geldig is.
  • 403 Forbidden betekent dat de referentieklasse of accountrol de bewerking niet mag uitvoeren.
  • 404 Not Found betekent dat de gevraagde resource niet zichtbaar is voor het geverifieerde account.
  • 422 Unprocessable Content betekent dat een of meer ingediende waarden een resourceregel schenden.

Gedeelde tagbudgetten

Maak een positieve beveiligingsregel in de modus block en koppel de guardrail_id en een hoofdlettergevoelige tag zoals dept:ml. Kies precies één doel, api_token_id, account_user_id of tag. Tagbudgetten vereisen een beheerder. Uitgeschakelde budgetten handhaven geen limieten. Beheerverzoeken verbruiken geen budget.

Budgetten verzamelen de huidige tags van standaardsleutels, inclusief uitgaven van verwijderde, uitgeschakelde en verlopen sleutels. Een tag toevoegen of verwijderen verplaatst de uitgaven van die sleutel voor de huidige periode. Een budget aanmaken of opnieuw aanmaken zet uitgaven nooit op nul. De telling sluit verwijderde sleutels uit. Elk passend budget moet het verzoek toestaan; een afwijzing retourneert 403 en de tagnaam.

Een lege credit_limit_reset_interval betekent een levenslange limiet. Andere perioden gebruiken UTC. De waarschuwingsdrempel is standaard 80 en accepteert 1 tot en met 100. Directe wijzigingen gelden voor alle koppelingen; het dashboard kopieert eerst het beleid bij wijzigingen aan een tagbudget.

Toelating controleert reserveringen. De afrekening kan deze overschrijden, gebruik boven 100% tonen en latere betaalde verzoeken blokkeren. Logboeken gebruiken hun aanmaaktijd; openstaande taken en batches hun eigen aanmaaktijd. Een taak uit een eerdere periode kan in een latere periode worden afgerekend.