AdAce AdsChiavi API di AdAce Ads: scope, scadenza, verifica e revoca
Una chiave API di AdAce Ads autentica un client MCP supportato o un'integrazione REST senza un accesso interattivo a ogni richiesta. È una credenziale, non un token Google o Meta. Creane una solo per un'integrazione e uno spazio di lavoro specifici, inizia con lo scope minimo e controlla cosa può leggere effettivamente l'integrazione.
Cosa autorizza una chiave
Una chiave è legata al suo spazio di lavoro e al suo utente. Le sue autorizzazioni effettive sono l'intersezione tra gli scope della chiave e il ruolo attuale dell'utente, con l'accesso ai client controllato dall'applicazione. Una modifica del ruolo può quindi ridurre ciò che una chiave esistente può fare. Copiare un identificatore dello spazio di lavoro in una richiesta non concede l'accesso a quello spazio di lavoro. Usa read per il reporting; una chiave non può concedere autonomamente l'accesso a un client non assegnato o a un account provider disconnesso.
Il valore completo ak_prefix_secret viene restituito una sola volta alla creazione, mentre AdAce Ads archivia un hash per la verifica. Il prefisso mostrato identifica una chiave senza rivelarne il valore completo. Salva la credenziale completa nella configurazione approvata dei segreti dell'integrazione ricevente. Non inserirla in un messaggio AI ordinario, un URL, codice sorgente, screenshot o log di risoluzione dei problemi. Un valore salvato mancante non può essere recuperato dal prefisso: crea una sostituzione e revoca la chiave persa.
Tramite REST, le chiavi consentono letture e, con scope propose, la creazione di proposte di modifica; non consentono direttamente approvazione, esecuzione o modifiche alle impostazioni. Tuttavia una proposta non è intrinsecamente inerte: la politica automatica configurata di un client può far procedere una proposta idonea entro le autorizzazioni e i limiti applicabili. MCP applica inoltre controlli di scope e ruolo agli strumenti disponibili. Usa read per una prova di reporting invece di presumere che propose garantisca la revisione umana di ogni azione successiva.
Ad esempio, crea una chiave read chiamata 'Report settimanale North Store' con una scadenza adeguata al periodo di revisione. Configura il client supportato per inviarla come credenziale Authorization Bearer all'endpoint documentato. Chiama get_started tramite MCP, poi leggi l'elenco degli account del client autorizzato. Confronta un account riconoscibile con l'applicazione. Questo dimostra un percorso di lettura utile senza creare proposte o modificare la pubblicità.
Credenziali con proprietario e scopo chiari
- Assegna a ogni integrazione affidabile una credenziale riconoscibile, così proprietà e scopo restano chiari quando rivedi l'accesso in seguito.
- Limita l'accesso con scope, autorizzazioni attuali dell'utente e legame con lo spazio di lavoro, invece di condividere una password dell'agenzia o un token del provider.
- Sostituisci la credenziale di un'integrazione quando serve e verifica la sostituzione prima di rimuovere la credenziale obsoleta durante la rotazione di routine.
Crea, verifica e ruota
- Apri Connect AI → Chiavi API nello spazio di lavoro previsto. Controlla nomi esistenti, numero di chiavi attive e timestamp dell'ultimo uso prima di creare un'altra credenziale.
- Crea una chiave con nome e scope read per la prima verifica. Seleziona una scadenza dove appropriato e completa eventuali requisiti di secondo fattore richiesti dall'applicazione.
- Salva il valore una tantum direttamente nella configurazione dei segreti dell'integrazione affidabile. Nel tuo inventario degli accessi conserva solo nome, prefisso, proprietario, scopo e scadenza.
- Usa l'integrazione per eseguire una lettura consentita. Controlla sia i dati restituiti sia l'attività pertinente o l'evidenza dell'ultimo uso; il timestamp dell'ultimo uso della chiave viene aggiornato al massimo una volta al minuto.
- Per la rotazione di routine, crea e verifica la sostituzione, passa alla nuova chiave nell'integrazione e revoca la vecchia chiave. Se una chiave è esposta, revocala tempestivamente e indaga sulla sua attività prima di configurare una sostituzione.
Limiti, errori e credenziali esposte
- Limite di creazione: l'implementazione consente cinque chiavi attive per persona in uno spazio di lavoro. Le chiavi scadute o revocate non occupano più uno slot attivo. Rivedi le integrazioni obsolete invece di condividere una chiave per evitare il limite.
- 401 o credenziale rifiutata: controlla endpoint, header Bearer, valore completo, scadenza e revoca. 403: controlla spazio di lavoro, scope effettivo, ruolo attuale e assegnazione del client. Una chiave read non dovrebbe essere ampliata solo perché una richiesta di impostazioni o proposta è stata rifiutata.
- Una risposta di rate-limit richiede di attendere secondo Retry-After e ridurre le chiamate ripetute; non significa che la chiave è stata revocata. La revoca della chiave blocca le autenticazioni successive ma non rimuove i report precedenti né annulla le modifiche. I test locali verificano le regole di implementazione, non l'accettazione dell'integrazione in produzione o la disponibilità pubblica a pagamento.
Fonti e approfondimenti
Provalo sui tuoi account
Crea uno spazio di lavoro, collega Google o Meta in un paio di clic e visualizza chiaramente i tuoi account. Le modifiche seguono le tue approvazioni o le regole che configuri.
Crea il tuo spazio di lavoro