HighLevel estende Snapshot e API pubbliche ai nuovi tipi di campi personalizzati

TL;DR: HighLevel ha aggiunto il supporto negli Snapshot e nelle API pubbliche per i tipi di campi personalizzati introdotti di recente: URL, Data e ora, testo ricco, Utenti e supporto alle immagini nei campi Radio e Checkbox. In pratica, le agenzie possono riutilizzare le configurazioni dei campi tra sotto-account senza ricrearle ogni volta; sviluppatori e integratori possono lavorare su questi campi via API. Il punto da verificare non è soltanto la presenza del campo, ma anche la compatibilità del proprio processo di clonazione, provisioning o sincronizzazione prima di applicarlo su account clienti.

In sintesi

Il cambiamento riguarda la portabilità e l’automazione dei nuovi campi personalizzati in HighLevel. Secondo l’annuncio ufficiale di HighLevel, gli Snapshot e le API pubbliche supportano ora tutti i tipi di custom field lanciati recentemente.

L’elenco indicato dalla fonte comprende:

• campi URL;
• campi Data e ora;
• campi di testo ricco;
• campi Utenti;
• supporto alle immagini nelle opzioni dei campi Radio e Checkbox.

La novità interessa due funzioni diverse ma complementari di GoHighLevel. Gli Snapshot servono a replicare configurazioni fra sotto-account; le API pubbliche consentono invece a software esterni, integrazioni e procedure sviluppate ad hoc di creare o gestire dati in modo programmatico. Un campo può quindi essere definito in un modello riutilizzabile e, dove il caso d’uso lo richiede, diventare parte di un flusso di sincronizzazione con un’applicazione esterna.

Cosa cambia per Snapshot e configurazione dei sotto-account?

I nuovi tipi di custom field possono essere inclusi negli Snapshot, evitando di ricrearne manualmente la configurazione su ogni sotto-account. Questa è la conseguenza operativa più immediata per agenzie, consulenti e team che impostano più location con una struttura dati ricorrente.

Prima di questo aggiornamento, la disponibilità dei nuovi campi non implicava necessariamente che la relativa configurazione potesse viaggiare con uno Snapshot. La fonte dichiara ora che il supporto è disponibile: una struttura che utilizza, per esempio, un campo Data e ora per una richiesta o un campo URL per una risorsa esterna può essere riutilizzata nella configurazione dei sub-account attraverso gli Snapshot.

Il vantaggio non consiste soltanto nel risparmio di tempo. Per chi opera su più clienti, una definizione coerente dei campi aiuta a mantenere allineati moduli, record e processi che dipendono da quei dati. Se un’agenzia usa lo stesso schema per acquisire informazioni di contatto, dettagli di progetto o collegamenti a risorse esterne, riduce il rischio che ogni account venga impostato con etichette, tipi o opzioni diversi.

Questo aggiornamento si collega al più ampio impiego degli Snapshot nella gestione delle entità del CRM. Per esempio, HighLevel ha già esteso gli Snapshot alle Smart List di Aziende e Oggetti personalizzati. In questo caso l’oggetto trasferibile è la configurazione dei nuovi campi personalizzati, non una promessa di trasferimento indistinto di ogni dato o automazione collegata: la fonte ufficiale parla specificamente di custom field configurations.

Cosa possono fare le API pubbliche con questi campi?

Le API pubbliche di HighLevel supportano ora anche i nuovi tipi di campo, così da permettere a sviluppatori e integrazioni di lavorare con essi programmaticamente. HighLevel indica fra gli effetti attesi la possibilità di sincronizzare dati dei custom field con applicazioni esterne e automatizzare processi che non devono dipendere esclusivamente da aggiornamenti manuali.

La documentazione tecnica collegata nell’annuncio è l’endpoint API per creare un custom field. Per un team tecnico, il cambiamento rende rilevante verificare che i payload, le validazioni e la gestione dei valori dell’integrazione esistente siano adeguati ai tipi di campo ora supportati.

Un esempio prudente: un gestionale esterno può avere l’esigenza di mantenere un riferimento URL o un’informazione temporale anche in HighLevel. Con il supporto API dichiarato, un’integrazione può essere progettata per operare su tali campi senza dover ripiegare su un campo di testo generico. La fonte non dettaglia però mapping, formati dei valori, limiti di richiesta, autenticazione o comportamento per ogni singolo tipo di campo. Questi aspetti vanno quindi confermati nella documentazione API aggiornata e testati nel proprio ambiente.

Per le aziende italiane che connettono HighLevel a CRM verticali, strumenti di prenotazione, ERP o portali proprietari, il valore concreto è una modellazione potenzialmente più fedele del dato. Non significa che l’integrazione sia pronta automaticamente: occorre definire quale sistema sia la fonte del dato, quali aggiornamenti prevalgano in caso di conflitto e come trattare eventuali valori non validi.

A chi serve davvero questo aggiornamento?

Serve soprattutto a chi replica configurazioni fra più account o mantiene integrazioni personalizzate con HighLevel. I profili più interessati sono:

• agenzie che creano e distribuiscono Snapshot per clienti o reparti;
• team di onboarding che standardizzano la struttura dei sotto-account;
• sviluppatori che usano le API pubbliche di GoHighLevel;
• aziende con applicazioni esterne che devono leggere, creare o aggiornare dati collegati ai campi personalizzati;
• operatori che hanno già attivato e adottato i nuovi custom field nei processi interni.

Per un singolo utente che non utilizza Snapshot né integrazioni API, l’impatto può essere limitato. La novità non annuncia nuove logiche di compilazione, nuove automazioni o nuove analisi dei dati; rende invece più riutilizzabili e integrabili tipi di campo già introdotti.

Quali passaggi indica HighLevel e cosa conviene controllare?

La fonte dichiara che il supporto è attivo in produzione e disponibile per tutti gli account; chi aveva già abilitato i nuovi campi tramite Labs può iniziare a usare le nuove capacità senza un’ulteriore attivazione. Non viene fornita una procedura UI dettagliata, quindi non è corretto trasformare questa nota in una sequenza certa di clic.

Un controllo operativo ragionevole, coerente con quanto pubblicato, è il seguente:

1. identificare se i processi del proprio account usano uno o più dei nuovi tipi di campo elencati;
2. per gli Snapshot, verificare su una configurazione di prova che i campi desiderati siano effettivamente presenti nel contenuto che si intende distribuire;
3. per le integrazioni, consultare la documentazione dell’endpoint API pertinente e provare i payload con dati rappresentativi;
4. verificare il comportamento delle applicazioni a valle, come moduli, workflow, report o sistemi esterni, quando ricevono valori di tipo URL, Data e ora, testo ricco, Utenti o opzioni con immagini;
5. documentare lo schema del dato prima di estendere il cambiamento agli account dei clienti.

Questa pagina aggiunge alla nota ufficiale un punto di vista operativo per chi lavora dall’Italia: il beneficio dipende dalla standardizzazione del modello dati e dalla qualità dell’integrazione, non dalla sola disponibilità tecnica del campo. La fonte non specifica, ad esempio, se e come eventuali workflow esistenti interpretino tutti i nuovi valori, né descrive la migrazione di configurazioni già distribuite. In assenza di tali dettagli, è opportuno evitare conclusioni automatiche.

Quali errori evitare prima di distribuire uno Snapshot o aggiornare un’integrazione?

L’errore più comune è confondere il supporto del tipo di campo con la validazione dell’intero processo che lo utilizza. La disponibilità in Snapshot e API non sostituisce i test su ciò che avviene prima e dopo il salvataggio del dato.

Da evitare in particolare:

• distribuire uno Snapshot su numerosi sotto-account senza una prova su un account controllato;
• trattare un campo Data e ora come se il formato e il fuso orario fossero irrilevanti per i sistemi collegati;
• assumere che un campo URL accetti o normalizzi ogni formato senza verificare le regole applicate dall’API o dall’integrazione;
• usare il testo ricco come semplice testo piano se l’applicazione esterna non è progettata per gestirne il contenuto;
• aggiornare via API campi Utenti o opzioni Radio e Checkbox con immagini senza controllare gli identificativi e le strutture richieste dalla documentazione;
• considerare uno Snapshot come sostituto di una strategia di aggiornamento dei dati già presenti nei sotto-account.

È utile anche separare il tema della configurazione da quello dei dati operativi: l’annuncio evidenzia la replica delle configurazioni dei campi tramite Snapshot e il lavoro programmatico sui campi tramite API, ma non descrive un meccanismo universale di sincronizzazione storica fra tutti gli account.

Disponibilità e denominazioni: cosa sapere

HighLevel dichiara che entrambe le funzionalità sono live in produzione e disponibili a tutti gli account alla data dell’annuncio. Se i nuovi tipi di campo erano già stati abilitati attraverso Labs, la fonte afferma che non è richiesta un’attivazione aggiuntiva per sfruttare Snapshot e API.

Nomi delle funzioni, interfaccia, requisiti e disponibilità possono cambiare dopo la data di verifica della fonte, indicata come 10 ottobre 2026. Prima di definire procedure interne o impegni verso clienti, conviene fare riferimento all’annuncio ufficiale e alla documentazione API corrente.

Per approfondire la standardizzazione delle configurazioni nei sotto-account, consulta la nostra guida editoriale sugli Snapshot e le Smart List di Aziende e Oggetti personalizzati. I risultati dipendono dalla struttura dei dati, dalle integrazioni attive e dal contesto operativo di ciascun account.