GoHighLevel e integrazioni API: come usare fino a 20 PIT token per subaccount

TL;DR: secondo il changelog ufficiale di HighLevel, il limite di Personal Integration Token (PIT) per ciascun subaccount è passato da 5 a 20. Per un’agenzia, il vantaggio operativo verificabile è poter assegnare token distinti a un numero maggiore di integrazioni esterne, invece di concentrare più collegamenti sullo stesso accesso. Questo non crea automaticamente nuove automazioni: rende però più ordinata e scalabile la loro gestione.

In sintesi

Un responsabile di agenzia conosce bene la situazione: un subaccount HighLevel nasce per gestire CRM e automazioni di un cliente, poi nel tempo si aggiungono un gestionale verticale, un sistema di appuntamenti, una dashboard di business intelligence, un’applicazione personalizzata o altri servizi esterni. Quando gli accessi API disponibili sono pochi, la soluzione più rapida tende a essere il riuso dello stesso token su più collegamenti.

Il processo manuale diventa fragile: bisogna ricordare dove è stato usato ogni accesso, distinguere le integrazioni necessarie da quelle non più attive e intervenire con cautela quando un collegamento deve cambiare. Il risultato non promesso è un incremento misurabile di vendite o di performance; il risultato operativo promesso dalla novità è più semplice e concreto: fino a 20 PIT token per subaccount, anziché 5, per organizzare un numero maggiore di accessi alle integrazioni API.

La fonte ufficiale è il changelog HighLevel, Increased PIT Token Limit per Subaccount, datato 27 luglio 2026. In base a quanto riportato, nomi delle funzioni, disponibilità e interfaccia possono cambiare dopo tale data.

La situazione di partenza

Risposta breve: il limite di cinque token poteva costringere a condividere lo stesso accesso API tra più servizi esterni.

HighLevel e GoHighLevel sono usati da agenzie, consulenti e PMI per centralizzare relazioni, marketing e automazioni. All’interno di questa architettura, il subaccount rappresenta il perimetro in cui può essere necessario connettere applicazioni di terze parti. I PIT token, o Personal Integration Token, sono chiavi API personali generate da HighLevel per autenticare e autorizzare la comunicazione fra un subaccount e strumenti esterni.

Il punto è importante perché un token non coincide con un workflow. Il token consente a un’applicazione esterna di collegarsi al subaccount; un workflow è invece il flusso di automazione costruito nella piattaforma. I due elementi possono partecipare allo stesso processo, ma hanno ruoli distinti.

Immaginiamo uno scenario ipotetico, non riferito a un cliente reale: un’agenzia italiana gestisce il subaccount di una PMI con un calendario o sistema di appuntamenti personalizzato, un CRM verticale e una soluzione di reportistica. Se ciascun collegamento richiede autenticazione API, usare un token separato per ogni integrazione rende più comprensibile quale accesso è associato a quale servizio. Con un limite di cinque token, la crescita dell’ecosistema poteva trasformare questa organizzazione in un vincolo.

Il problema quotidiano non è solo tecnico. Quando più servizi condividono lo stesso token, un aggiornamento, una dismissione o una revisione dell’accesso richiedono maggiore attenzione: occorre capire quali dipendenze esistono prima di modificare qualcosa. È il classico costo invisibile del processo manuale: appunti sparsi, nomi poco chiari e verifiche ripetute.

Cosa cambia con HighLevel

Risposta breve: il massimo ufficialmente indicato passa da 5 a 20 PIT token per ogni subaccount.

HighLevel ha quadruplicato il limite dei PIT token per subaccount. La fonte descrive l’aggiornamento come un ampliamento della flessibilità per integrazioni e automazioni: ogni token può essere dedicato a uno specifico servizio, riducendo la necessità di riutilizzare la stessa credenziale su più piattaforme.

Per le agenzie italiane, il cambiamento ha soprattutto una conseguenza di governance. Un subaccount con più collegamenti può essere strutturato per funzione o per applicazione: un token per il gestionale verticale, uno per la soluzione di business intelligence, uno per l’applicazione di appuntamenti personalizzata e così via. Questa separazione aiuta a mantenere leggibile la relazione fra HighLevel, il singolo strumento esterno e il processo che quell’integrazione supporta.

La fonte ufficiale parla anche di gestione API più scalabile e sicura. È corretto interpretarlo come possibilità di separare maggiormente gli accessi; non è invece corretto dedurre che la disponibilità di 20 token renda sicura qualunque integrazione o elimini la necessità di governare credenziali e autorizzazioni.

Il beneficio riguarda chi ha un ecosistema digitale articolato: agenzie con molti collegamenti per subaccount, consulenti che integrano software specifici e PMI che affiancano HighLevel ad applicazioni già presenti nei propri processi. Non è un obbligo usare tutti i 20 token e non è una ragione, da sola, per introdurre nuove integrazioni non utili.

Le API diventano particolarmente rilevanti quando un dato o un’azione devono passare tra sistemi diversi. Se il bisogno è interno alla piattaforma, può essere più pertinente lavorare sui flussi già disponibili: per esempio, la guida sui workflow GoHighLevel con Wait Step tratta l’organizzazione delle risposte del team, senza confondere questo tema con la gestione delle credenziali API.

Come configurare il flusso

Risposta breve: prima si mappano le integrazioni, poi si assegna un token distinto dove serve e infine si documenta il collegamento.

La fonte ufficiale conferma il nuovo limite, ma non dettaglia una procedura nella UI per creare, nominare, revocare o assegnare i PIT token. Per questo, i passaggi seguenti sono consigli editoriali di organizzazione, non istruzioni ufficiali di prodotto. Prima di operare, è opportuno consultare la documentazione aggiornata di HighLevel e verificare la schermata disponibile nel proprio account.

1. Fai l’inventario dei collegamenti esterni del subaccount. Elenca le applicazioni che comunicano con HighLevel tramite API o che richiedono un PIT token. Per ognuna, annota finalità, responsabile interno o fornitore e processo supportato. Non basta scrivere “integrazione”: meglio indicare, ad esempio, “reportistica”, “CRM verticale” o “appuntamenti personalizzati”.

2. Distingui i servizi attivi da quelli da verificare. Un token in uso e un’integrazione utile non sono necessariamente la stessa cosa. Prima di espandere gli accessi, chiarisci quali collegamenti fanno davvero parte del flusso attuale. Questa revisione riduce il rischio di portarsi dietro configurazioni non documentate.

3. Definisci un criterio di separazione. Il criterio più leggibile è spesso un token per integrazione esterna. In alcuni casi può essere utile separare anche per ambiente, finalità o responsabile tecnico, ma questa è una scelta organizzativa da valutare nel proprio contesto. Il dato ufficiale è il limite di 20 per subaccount, non un modello obbligatorio di suddivisione.

4. Crea o assegna i token secondo le procedure aggiornate. Usa le istruzioni ufficiali disponibili al momento dell’attività. L’interfaccia può cambiare e la fonte fornita non indica i passaggi di menu né il comportamento di eventuali token esistenti. Evita quindi di trattare questa novità come una procedura universale da replicare alla cieca.

5. Aggiorna le applicazioni esterne una alla volta. Se l’obiettivo è sostituire un token condiviso con token dedicati, procedere per singola integrazione rende più semplice attribuire un eventuale problema al collegamento corretto. Verifica il funzionamento previsto dal servizio esterno prima di considerare conclusa la modifica.

6. Mantieni un registro essenziale. Per ogni token, conserva in un luogo controllato almeno il servizio associato, la finalità e il referente. Il valore dell’aumento del limite non sta nell’accumulare chiavi: sta nel rendere tracciabile l’accesso API nel tempo.

Questo metodo può affiancare, non sostituire, la progettazione dei processi in HighLevel. Se l’integrazione alimenta automazioni, documenta anche quale workflow riceve o usa i dati. Per interventi mirati sulla logica dei flussi, può essere utile approfondire come ottimizzare i Workflow GoHighLevel con AI Builder, ricordando che il PIT token resta una credenziale di integrazione e non un generatore automatico di workflow.

Il risultato operativo

Risposta breve: un subaccount può disporre di fino a 20 accessi PIT, con più margine per separare i collegamenti esterni.

Il risultato verificabile dell’aggiornamento è l’aumento del tetto: da cinque a venti PIT token per subaccount. In termini operativi, questo permette di pianificare una maggiore separazione fra applicazioni esterne senza arrivare così rapidamente al limite precedente.

Per un’agenzia, il vantaggio pratico è poter collegare HighLevel a più servizi nel perimetro di uno stesso subaccount e associare più chiaramente token e integrazioni. In caso di revisione di un collegamento, la documentazione interna può indicare quale token appartiene a quello specifico servizio, evitando di trattare una credenziale condivisa come se fosse isolata.

Non va però confuso il potenziale organizzativo con un risultato garantito. La fonte non dichiara tempi di implementazione, riduzione di errori, aumento di conversioni, compatibilità con specifiche applicazioni o quantità di automazioni attivabili. Ogni risultato dipende dal numero reale di strumenti, dalla loro configurazione, dalle API dei servizi coinvolti e dalla qualità della gestione interna.

Errori e limiti

Risposta breve: avere più token non sostituisce una strategia di integrazione, né rende automaticamente affidabile un flusso.

Il primo errore è chiamare “automazione” qualunque collegamento API. Il PIT token abilita autenticazione e autorizzazione verso un’applicazione esterna; il comportamento del flusso dipende poi da configurazioni, dati e capacità degli strumenti connessi.

Il secondo è creare token senza una convenzione. Con 20 accessi disponibili, il disordine può aumentare se non si registra a cosa serve ogni token. Un elenco aggiornato e nomi coerenti, se l’interfaccia li consente, sono misure organizzative più utili dell’uso indiscriminato del nuovo limite.

Il terzo errore è usare l’aumento del limite come prova di compatibilità universale. Il changelog afferma che è più facile connettere un maggior numero di piattaforme e applicazioni di terze parti, ma non elenca servizi specifici né garantisce il funzionamento di ogni software. Ogni integrazione va valutata e testata secondo la documentazione aggiornata delle due parti.

Infine, non modificare o sostituire un token condiviso senza sapere quali servizi lo utilizzano. È proprio qui che il problema iniziale del responsabile — non sapere più dove passa ogni collegamento — rischia di ripresentarsi. I 20 PIT token offrono più spazio per prevenire quella confusione; la disciplina di gestione resta a carico dell’agenzia o dell’azienda.

Se stai strutturando anche la comunicazione operativa oltre alle integrazioni, puoi valutare il nostro bonus WhatsApp per GoHighLevel. È un approfondimento complementare: risultati e configurazioni variano sempre in base al contesto, agli strumenti collegati e ai processi del singolo subaccount.