Una volta che hai la chiave, autentica ogni richiesta aggiungendo l'intestazione `X-API-Key` con il valore completo della chiave. Non serve nessun altro dato di sessione — né cookie, né token Bearer. Esempio reale, elencando le tue stesse chiavi: ``` curl -X GET "https://TUO_DOMINIO/api/v1/auth/api-keys" \ -H "X-API-Key: aa_TUA_CHIAVE_COMPLETA_QUI" ``` Risposta (200, esempio reale abbreviato): ``` [ { "id": "985d256e-9809-...", "name": "La mia integrazione", "prefix": "aa_1b2e1ebd", "scopes": ["tenant:config.manage", "tenant:content.manage", "tenant:self.manage"], "expires_at": null, "last_used_at": "2026-08-23T05:36:27Z", "is_active": true, "owner_type": "user", "allowed_origins": [], "created_by": "admin@tua-attivita.it" } ] ``` Una **chiave d'azienda** (paragrafo 5) autentica esattamente allo stesso modo, senza sessione né credenziali personali — l'account di servizio del tenant risponde con le proprie chiavi (esempio reale): ``` curl -X GET "https://TUO_DOMINIO/api/v1/auth/api-keys" \ -H "X-API-Key: aa_9fe72924…" ``` Risposta (200, esempio reale abbreviato — nota `"owner_type": "tenant"`): ``` [ { "id": "8a0b0f78-7b25-...", "name": "AK-18 fix round 1 demo", "prefix": "aa_9fe72924", "scopes": ["tenant:config.manage", "tenant:content.manage", "tenant:self.manage"], "expires_at": null, "last_used_at": "2026-08-23T06:28:37Z", "is_active": true, "owner_type": "tenant", "allowed_origins": [], "created_by": "admin@tua-attivita.it" } ] ``` > **Nota — Cosa NON permette una chiave API** > > Autentica chiamate all'API REST con i permessi del suo ruolo sigillato (paragrafo 7) — nient'altro. Nello > specifico: non serve per accedere all'interfaccia web della Piattaforma (quella resta email + password, > oppure Google), non è la stessa cosa dell'«Accesso per canale» di WhatsApp/Telegram (Manuale 51, un > meccanismo diverso basato sulla verifica in due passaggi), e non dà accesso per vedere la chiave di > un'altra persona né le chiavi di un altro tenant.