Vai al contenuto principale
Quasi mai usi una sola chiave. Un workspace reale ha una chiave di produzione, una di staging, la chiave locale di uno sviluppatore, magari una usa-e-getta per un load test — tutte che chiamano gli stessi modelli attraverso lo stesso gateway. Distinguile con il tag environment: una breve etichetta libera che imprimi su ogni chiave così che la console, il tuo team e la tab Usage Tracking possano raggruppare le chiavi per dove girano. Questo è il piccolo campo organizzativo, non uno di applicazione — non cambia ciò che una chiave può fare. Per i limiti che vincolano una chiave (modelli, IP, spesa, scadenza, policy) parti dalla panoramica delle chiavi con scope.

​
1. Perché il tag environment delle chiavi API

Quando ogni chiave appare come sk-orca-•••• nell’elenco, non puoi distinguere la chiave di produzione da una chiave dev usa-e-getta — ed è esattamente la chiave che non vuoi ruotare, revocare o a cui alzare un cap di spesa per sbaglio. Il tag environment trasforma una credenziale anonima in una etichettata:
  • A colpo d’occhio — l’elenco delle chiavi mostra quali chiavi sono prod, staging o dev, così agisci su quella giusta.
  • Per spesa — la tab Usage Tracking può aggregare la spesa per environment, così “quanto ci sta costando staging questa settimana” è un filtro, non un foglio di calcolo.
  • Per convenzione — un vocabolario condiviso (prod / staging / dev) in tutto il workspace, così un compagno di squadra che legge l’elenco capisce il tuo layout senza chiedere.
Il tag è libero e puramente descrittivo. Non controlla modelli, IP, spesa o policy — quelli sono gli altri campi della chiave. Due chiavi taggate prod non ricevono alcun trattamento speciale oltre a condividere un’etichetta.

​
2. Cosa accetta il campo

environment è un’etichetta testuale opzionale e breve sul key object:
ProprietàComportamento
TipoStringa libera — nessun enum fisso. prod, staging, dev sono convenzioni, non valori predefiniti.
LunghezzaRipulita degli spazi circostanti e limitata a 32 caratteri; qualsiasi cosa più lunga viene troncata.
Vuoto / non impostatoUna chiave senza tag viene riletta come stato unlabeled e confluisce in un segmento unlabeled in Usage Tracking.
Effetto sul trafficoNessuno — puramente organizzativo.
Scegli un vocabolario piccolo e stabile e attieniti a quello. prod, staging, dev bastano per la maggior parte dei team; è la coerenza che rende utile il tag quando filtri la spesa. Un campo a testo libero con prod, Prod e production dentro vanifica lo scopo.

​
3. Imposta il tag su una chiave

Imposta environment nell’editor delle chiavi nella console (/console/token) — lo stesso posto in cui imposti i limiti sui modelli e i collegamenti a policy. Creare o modificare chiavi richiede il ruolo Developer o superiore.
1

Apri la chiave

Nella console vai su Chiavi (/console/token) e crea una nuova chiave o modificane una esistente.
2

Imposta l'etichetta environment

Inserisci una breve etichetta — es. prod — nel campo Environment. Tienila sotto i 32 caratteri.
3

Salva

Il tag è ora collegato alla chiave. Appare nell’elenco delle chiavi e diventa disponibile come dimensione di Usage Tracking.
Modificare una chiave per cambiare un campo non correlato (una rinomina, un nuovo cap di spesa) preserva il tag environment esistente — il tag viene cambiato solo quando lo imposti esplicitamente. Per cancellare un tag, imposta il campo a un valore vuoto; è un reset intenzionale allo stato unlabeled.

​
4. Segmentare la spesa per environment

Una volta taggate le chiavi, la tab Usage Tracking (console → Overview) può raggruppare spesa, richieste e token per la dimensione environment. Aggrega l’uso di ogni chiave sotto la sua etichetta environment, con le chiavi non taggate raccolte sotto unlabeled. Questo risponde a domande che la vista per chiave non può, al livello a cui effettivamente fai budget:
  • Quanto sta spendendo staging rispetto a prod questa settimana?
  • La nuova chiave dev ha sforato quel che ci aspettavamo?
  • Quale environment ha guidato il picco di martedì?
La stessa vista segmenta anche per chiave, modello, membro e task del caso d’uso — environment è quella che mappa a dove è girato il traffico. La segmentazione della spesa legge solo le righe di consumo, con scope sul tuo workspace, così i numeri tornano con Billing.
La dimensione environment legge l’etichetta corrente su ogni chiave quando carichi il report. Ri-taggare una chiave cambia come la sua spesa storica viene aggregata la prossima volta che apri la vista — il tag è una proprietà viva della chiave, non un timbro congelato sulle richieste passate.

​
5. Un esempio svolto: tre chiavi, un workspace

Un piccolo team che gestisce un prodotto su tre environment:
ChiaveenvironmentAltro scope (la parte che applica davvero)
Agent di produzioneprodfirewall_policy_id stretta, credit_limit_usd settimanale, allow_ips fissata
Agent di stagingstaginguna policy del firewall permissiva in shadow mode, un cap più basso
Dev localedevmodel_limits a un unico modello economico, expired_time ravvicinato
I tag non cambiano nessuno di quei limiti — rendono le tre chiavi leggibili. L’elenco si legge a colpo d’occhio, la tab Usage mostra tre barre di spesa anziché tre id di chiave opachi, e quando ruoti la chiave prod sei certo di aver preso quella giusta.
Abbina il tag environment a un’applicazione reale così che ogni chiave sia sia etichettata sia vincolata. Il tag ti dice cos’è una chiave; la checklist di minima agenzia si assicura che non possa fare più di quanto quell’environment richieda.

​
6. Tag vs. applicazione — non confondere le due cose

Il tag environment è il campo più leggero su una chiave. È facile ricorrervi come controllo di sicurezza; non lo è. Se vuoi che una chiave dev sia incapace di colpire i modelli di produzione o di spendere denaro reale, l’etichetta non lo farà — lo faranno i campi di applicazione:

Limiti sui modelli

model_limits è ciò che davvero impedisce a una chiave dev di chiamare un modello di frontiera — non il tag dev.

Quota, cap e scadenza

credit_limit_usd ed expired_time vincolano spesa e durata. Il tag organizza; questi vincolano.

Collegare le policy

guardrail_id e firewall_policy_id collegano le policy sui contenuti e sulle chiamate a tool che governano il traffico della chiave.

Il token object

Il riferimento completo campo per campo di una chiave, tag environment incluso.

​
7. Dove si colloca

Il tag environment è una fetta del modello delle chiavi più ampio — identità ristrette ed etichettate per ogni agent e ogni luogo in cui gira.

Panoramica chiavi con scope

L’hub per ogni campo che una chiave porta.

Scope e chiavi

Come workspace, policy e chiavi si annidano insieme.

Gestire le chiavi

Crea, modifica e revoca le chiavi nella console.
Un tag è l’investimento più economico in un workspace ordinato: pochi caratteri per chiave, e la differenza tra un elenco che puoi leggere e uno che non puoi. Imprimi su ogni chiave il suo environment nell’istante in cui la crei — e lascia che gli altri campi facciano l’applicazione.