Skip to main content
Een API-sleutel authenticeert je verzoeken aan Novita AI. Deze pagina behandelt hoe sleutels werken, hoe je er een aanmaakt en opslaat, en hoe je ervoor zorgt dat deze in al je omgevingen blijft werken. Gebruik deze pagina om:
  • Verzoeken aan Novita AI te authenticeren met een Bearer API-sleutel.
  • Een API-sleutel aan te maken vanuit de console en deze veilig op te slaan.
  • Je sleutel te configureren als omgevingsvariabele op Linux, macOS en Windows.
  • Te begrijpen hoelang een sleutel geldig blijft en wat de OpenAPI wel en niet dekt.

Authenticatie

Novita AI authenticeert API-toegang met Bearer-authenticatie. Stuur je API-sleutel in de Authorization verzoekheader:
Een voorbeeldverzoek:

Maak een API-sleutel aan

1

Open Sleutelbeheer

Ga naar Sleutelbeheer in de console.
2

Maak een nieuwe sleutel aan

Selecteer API-sleutel aanmaken en geef de sleutel vervolgens een naam die het doel ervan weerspiegelt, zoals production of local-testing.
3

Kopieer de sleutel en sla deze op

De volledige sleutel wordt slechts één keer weergegeven, bij het aanmaken. Kopieer deze onmiddellijk en sla deze op een veilige plek op, zoals een secretsmanager of een omgevingsvariabele. Als je deze verliest, kun je deze niet herstellen — maak in plaats daarvan een nieuwe sleutel aan.
Optioneel kun je beperken welke modellen een sleutel mag aanroepen. Zie Modeltoegang voor API-sleutels.

Sleutelformaat en geldigheid

  • Elke sleutel begint met de sk_ voorvoegsel.
  • Een sleutel wordt slechts één keer volledig weergegeven, bij het aanmaken. Daarna toont de console een gemaskeerde vorm.
  • Een sleutel blijft na het aanmaken onbeperkt geldig. Deze blijft werken totdat je deze in de console verwijdert.
  • Elk account kan maximaal 10 API-sleutels aanmaken.

Wat de OpenAPI omvat

Je maakt en verwijdert API-sleutels uitsluitend in de console. De Novita OpenAPI bevat geen endpoints om sleutels aan te maken of te verwijderen. De sleutelgerelateerde OpenAPI-endpoints omvatten het weergeven van sleutels en het beheren van het modeltoegangsbeleid van een sleutel:

Sla je sleutel op als een omgevingsvariabele

Het hardcoderen van een sleutel in broncode brengt het risico met zich mee dat deze uitlekt, bijvoorbeeld wanneer je het bestand commit. Het lezen van de sleutel uit een omgevingsvariabele zoals NOVITA_API_KEY houdt het uit je code.

Tijdelijk vs. permanent

Een sleutel die is ingesteld met export (Linux/macOS) of set (Windows) blijft alleen geldig voor de huidige terminalsessie en is weg wanneer je die sluit. Dat is prima voor een snelle test. Om de sleutel tussen sessies te behouden, stel je deze permanent in zoals hieronder weergegeven en open je daarna een nieuwe terminal zodat de wijziging van kracht wordt.
Lees de sleutel in je code terug uit de omgeving:

De variabele is ingesteld, maar de code kan deze nog steeds niet vinden

Een sleutel ingesteld met export of $env: bestaat alleen in de terminalsessie waarin je deze hebt uitgevoerd. Een nieuwe terminal, of een nieuw tabblad, neemt deze niet over. Stel de sleutel permanent in (>> ~/.zshrc, setx), of herhaal de export/$env: regel in de sessie die je gebruikt.
Een permanente wijziging (shellprofiel, setx) is van toepassing op terminals die na de wijziging zijn gestart. Open een nieuwe terminal en start je IDE of editor opnieuw op zodat deze de nieuwe omgeving overneemt. Op Windows, setx is niet van invloed op terminals die al geopend zijn.
Processen die worden gestart door systemd, supervisor, Docker of een CI-runner lezen je interactieve shellprofiel niet. Stel de variabele in de eigen configuratie van de service in (bijvoorbeeld een systemd van de eenheid Environment=, een docker run -e flag, of de secrets van het CI-project), niet in ~/.bashrc.
sudo geeft je omgeving standaard niet door, dus de variabele die je als je gebruiker hebt geëxporteerd is niet zichtbaar voor het proces met verhoogde rechten. Gebruik sudo -E om de omgeving te behouden, of stel de variabele in binnen de verhoogde context.

Gerelateerd

Laatst gewijzigd op 10 augustus 2026