L'API Google Places (Legacy) è congelata: cosa devono fare gli sviluppatori EU prima che inizi il conto alla rovescia

Google ha congelato la Places API legacy nel marzo 2025. Funziona ancora, ma non riceverà nuove funzionalità e la deprecazione si avvicina. Per gli sviluppatori EU, la decisione di migrazione è più complicata di quanto la documentazione di Google suggerisca.

Nel marzo 2025, Google ha silenziosamente ristrutturato la sua piattaforma di mappatura in modi che hanno creato una vera urgenza per gli sviluppatori, anche se il messaggio era formulato con toni morbidi. La Places API legacy, la Directions API e la Distance Matrix API sono state tutte riclassificate come "servizi Legacy". Funzionano ancora. Continueranno a funzionare fino a quando Google non annuncerà una data di deprecazione. Ma sono state congelate.

Nessuna nuova funzionalità. Nessun miglioramento architetturale. Sconti sul volume limitati al livello 100.000+, al di sotto di ciò di cui le applicazioni più grandi hanno bisogno. E da qualche parte nel futuro, un annuncio di deprecazione con 12 mesi di preavviso.

Per la maggior parte degli sviluppatori, la domanda non è se migrare. È quando, e verso cosa.

Per gli sviluppatori EU in particolare, il calcolo è diverso. La decisione di migrazione coinvolge non solo la compatibilità delle API e i prezzi, ma anche la conformità al GDPR, la residenza dei dati e il rischio legale dell'infrastruttura statunitense che la stessa documentazione di Google non tratta completamente.

Questa guida copre cosa è cambiato, cosa comporta la migrazione e le domande che i team EU dovrebbero porsi prima di scegliere una direzione.

Cosa ha cambiato Google nel marzo 2025

La ristrutturazione del marzo 2025 aveva due componenti distinte che molti sviluppatori hanno confuso.

Ristrutturazione dei prezzi: Google ha sostituito il credito mensile forfettario di 200 $/mese con livelli gratuiti per SKU. Invece di un unico credito applicabile a qualsiasi combinazione di API, ogni tipo di API ha ora il proprio livello gratuito:

• Geocoding API: 10.000 eventi gratuiti/mese, poi 2-7 $ per 1.000
• Maps JavaScript API: 10.000 eventi gratuiti/mese
• Places API (New): livello gratuito per tipo di richiesta
• Routes API: livello gratuito per tipo di percorso

Per gli sviluppatori che usavano intensivamente una singola API sotto il vecchio credito di 200 $, il nuovo modello può significare costi maggiori. Per gli sviluppatori distribuiti su più tipi di API, i livelli gratuiti per SKU possono effettivamente ridurre i costi. L'unico modo per saperlo è verificare l'utilizzo attuale rispetto alla nuova struttura SKU.

Parallelamente al cambio di prezzi, Google ha lanciato piani in abbonamento: Starter a 100 $/mese (50.000 chiamate combinate), Essentials a 275 $/mese (100.000 chiamate combinate) e Pro a 1.200 $/mese (250.000 chiamate combinate). Questi piani mirano a dare prevedibilità a scala, ma aggiungono un ulteriore livello di complessità alla proiezione dei costi.

Designazioni di deprecazione delle API: Separatamente, Google ha designato tre API come servizi Legacy:

• Places API (Legacy): sostituita dalla Places API (New)
• Directions API: sostituita dalla Routes API
• Distance Matrix API: sostituita dalla Routes API con computeRouteMatrix

La designazione Legacy significa che queste API non ricevono nuove funzionalità e non sono idonee per i nuovi livelli di sconto sul volume estesi. Sono in modalità manutenzione.

Cosa cambia davvero la Places API (New)

La Places API (New) non è un sostituto plug-and-play. Ha un formato di richiesta diverso, una struttura di risposta diversa e un modello di selezione dei campi diverso.

Il cambiamento più significativo è il masking dei campi. La API legacy restituisce una struttura di risposta fissa. La nuova API richiede di specificare i campi necessari tramite un header di field mask. Questo riduce il trasferimento di dati non necessario e significa che paghi solo per i campi che richiedi, ma significa anche che ogni chiamata API nel tuo codebase deve essere aggiornata con field mask espliciti.

Differenze chiave che gli sviluppatori incontrano durante la migrazione:

Formato della richiesta: La nuova API usa richieste POST con un corpo JSON invece di richieste GET con parametri query. Se la tua integrazione costruisce chiamate basate su URL, ogni chiamata deve essere ristrutturata.

Struttura della risposta: I nomi dei campi sono cambiati. formatted_address diventa formattedAddress (camelCase). place_id diventa id. L'oggetto geometry è ristrutturato. Il codice di parsing delle risposte deve essere verificato nell'intero progetto.

Nuove funzionalità solo nella Places API (New): Riepiloghi IA generativi, nuovi campi dati per le stazioni di ricarica elettrica, prezzi del carburante, dettagli sull'accessibilità e suggerimenti di completamento automatico migliorati. Se hai bisogno di una qualsiasi di queste funzionalità, devi migrare.

Gestione delle foto: Il formato di riferimento delle foto è cambiato. Gli URL delle foto generati dalla API legacy smetteranno eventualmente di funzionare, quindi tutti i riferimenti foto memorizzati nella cache devono essere rigenerati.

Google fornisce guide alla migrazione, ma l'esperienza pratica è che la migrazione è un compito di ingegneria significativo, non un semplice cambio di configurazione. I team in genere prevedono da una a quattro settimane a seconda della complessità dell'integrazione.

La migrazione della Routes API (separata ma correlata)

La Directions API e la Distance Matrix API seguono un modello simile. Il sostituto è la Routes API, che usa un formato di richiesta/risposta diverso e offre funzionalità che le API legacy non hanno: routing con consapevolezza del traffico, modificatori di percorso, supporto per i due ruote e ottimizzazione dell'efficienza del carburante.

La Routes API ha anche prezzi diversi. La Directions API legacy prezzava per elemento (coppia origine-destinazione). La Routes API prezza per richiesta di percorso e per elemento nelle richieste matriciali. Per le applicazioni che effettuano grandi volumi di richieste matriciali, i costi potrebbero cambiare significativamente.

Se stai migrando la Places API, vale la pena pianificare la migrazione della Routes API contemporaneamente invece di eseguire due migrazioni separate. Lo sforzo parallelo è più efficiente di migrazioni sequenziali che richiedono ciascuna i propri cicli di test e distribuzione.

Le considerazioni specifiche per l'EU

È qui che la decisione di migrazione diventa più articolata per gli sviluppatori europei rispetto a quanto suggerisca la documentazione di Google.

GDPR e trasferimenti di dati transfrontalieri

Google Maps Platform è un'infrastruttura statunitense. Quando il browser di un utente effettua una richiesta alla Places API o carica una mappa, quella richiesta transita attraverso i server statunitensi di Google. Ai sensi del GDPR, si tratta di un trasferimento di dati transfrontaliero.

La base giuridica attuale per questi trasferimenti è il Quadro per la Privacy dei Dati UE-USA, che ha sostituito l'accordo Privacy Shield invalidato dalla sentenza Schrems II nel 2020. Il DPF è già stato contestato legalmente e la sua stabilità a lungo termine non è garantita. Per le aziende in settori regolamentati (sanità, fintech, servizi legali, applicazioni vicine al governo), la continua dipendenza dall'infrastruttura statunitense è una conversazione di conformità continua che richiede monitoraggio.

L'utilizzo delle API di Google Maps richiede anche il consenso ai cookie per la JavaScript API in alcune implementazioni, poiché gli indirizzi IP degli utenti e gli identificatori dei dispositivi vengono inviati a Google. Per le applicazioni che vogliono caricare mappe senza attivare un banner di consenso, l'infrastruttura ospitata negli USA crea un problema strutturale.

Google ha aggiornato i propri Termini di Servizio per Google Maps Platform SEE nel 2025 per applicarsi specificamente agli indirizzi di fatturazione EU. Gli sviluppatori dovrebbero esaminare i termini aggiornati rispetto ai propri requisiti DPA.

Semplificazione della conformità come trigger per la migrazione

Per molti team EU, i cambiamenti di marzo 2025 hanno fornito un trigger pratico per rivalutare se restare nell'ecosistema Google o passare a un'alternativa ospitata nell'UE.

La logica per la rivalutazione è semplice: se stai comunque per investire tempo di ingegneria in una migrazione (dalla Places API legacy alla Places API New), lo sforzo marginale aggiuntivo per migrare verso un altro fornitore è spesso più piccolo di quanto sembri. Le modifiche agli endpoint API, il lavoro di mappatura dei campi e i cicli di test sono in gran parte gli stessi sia che tu stia migrando alla nuova API Google sia verso un'alternativa di terze parti. La differenza sta in ciò che ottieni alla fine.

Un'API di mappatura ospitata nell'UE elimina completamente il problema del trasferimento transfrontaliero GDPR. Tutte le richieste rimangono nell'UE. Nessuna CSC da negoziare, nessuna dipendenza dal DPF, nessun consenso ai cookie richiesto per caricare una mappa. Per le aziende che hanno recentemente completato audit GDPR o ne prevedono uno, questa semplificazione ha un valore organizzativo reale.

Valutare se migrare all'interno di Google o cambiare fornitore

Il framework onesto per questa decisione ha quattro parti.

1. Verifica il tuo utilizzo attuale delle API

Prima di prendere qualsiasi decisione, mappa ogni chiamata alla Places API, alla Directions API e alla Distance Matrix API nel tuo codebase. Conta il volume per tipo di endpoint. Mappalo sia al modello di prezzi della Places API (New) sia agli endpoint equivalenti nei fornitori alternativi candidati.

Il confronto dei costi ha senso solo con dati di utilizzo reali. Le stime approssimative basate sul volume totale delle richieste non sono sufficienti perché le diverse API dello stesso fornitore hanno prezzi diversi.

2. Valuta la tua esposizione al GDPR

Chiedi al tuo team legale o di compliance quanto rischio continuativo rappresenta la dipendenza dall'infrastruttura statunitense per il tuo contesto specifico. Per un prodotto SaaS con clienti enterprise EU che hanno DPA in atto, il livello di rischio è diverso rispetto a un'applicazione consumer che elabora dati personali sensibili.

Se la semplificazione della conformità ha valore, assegnale un costo. Il carico legale interno legato al mantenimento delle CSC, al monitoraggio della stabilità del DPF e alla gestione dei questionari di conformità dei clienti è lavoro reale con costi reali.

3. Valuta lo sforzo di migrazione per ciascun percorso

Migrare alla Places API (New) all'interno di Google: stima in base alla complessità della tua integrazione. Modifiche al field masking, ristrutturazione delle richieste, aggiornamenti del parsing delle risposte. Tipicamente da una a quattro settimane di sforzo di ingegneria.

Migrare verso un'alternativa di terze parti: portata di ingegneria simile. Modifiche agli URL degli endpoint, differenze nei parametri, differenze nel formato delle risposte. Per i team che usano già MapLibre GL JS come layer di rendering (il fork open-source di Mapbox GL JS), il layer di rendering rimane lo stesso. Cambiano solo le chiamate di geocodifica, ricerca e routing.

4. Considera cosa ottieni dall'altra parte

La Places API (New) ti dà accesso alle ultime funzionalità di Google: autocompletamento migliorato, riepiloghi IA generativi, dati sui luoghi arricchiti. La copertura dei dati di Google è insuperata a livello globale.

Le alternative ospitate nell'UE come MapAtlas offrono conformità GDPR by design, residenza dei dati nell'UE e in alcuni casi strumenti di visibilità nella ricerca IA che le API di Google non forniscono. Per le applicazioni nel settore immobiliare, dell'ospitalità o della logistica dove la rilevabilità IA delle pagine di localizzazione è importante, il layer di visibilità IA è un differenziatore significativo.

Nessun percorso è universalmente corretto. La risposta giusta dipende dai tuoi requisiti di conformità, dalla sensibilità ai prezzi e dalle funzionalità più importanti per la tua applicazione.

Cosa fare adesso

Indipendentemente dal percorso di migrazione che scegli, alcune azioni hanno senso immediatamente:

Verifica e documenta la tua superficie API attuale: Sappi esattamente quali endpoint legacy usi, con quale frequenza e da quali campi dati dipendi. Queste informazioni sono necessarie per qualsiasi decisione di migrazione.

Esegui il confronto dei prezzi con dati reali: Usa i tuoi dati di utilizzo effettivi per confrontare i prezzi legacy, i prezzi della Places API (New) e i fornitori alternativi. Fallo al tuo volume attuale e a 2 volte il tuo volume attuale.

Controlla la tua documentazione GDPR: Esamina il tuo DPA attuale con Google, le tue CSC o la dipendenza dal DPF e la tua implementazione del consenso ai cookie. Comprendi la tua posizione giuridica attuale prima di modificarla.

Non migrare sotto pressione temporale: La API legacy funziona ancora. È congelata, non rotta. Prendi la decisione di migrazione con dati chiari e margine di ingegneria adeguato piuttosto che affrettarti a causa di un'urgenza percepita. L'annuncio di deprecazione ti darà 12 mesi di preavviso.

Fissa una scadenza per la decisione: "Quando Google annuncia la deprecazione" non è un piano. Fissa un punto di decisione interno su quale percorso di migrazione intraprendere, idealmente nel trimestre successivo.

Se vuoi confrontare come appaiono concretamente le API di mappatura ospitate nell'UE in termini di superficie API, prezzi e sforzo di migrazione, MapAtlas copre geocodifica, completamento automatico degli indirizzi, routing e tile cartografiche sotto un unico modello di prezzi con residenza dei dati nell'UE. La pagina dei prezzi mostra la struttura dei livelli attuali, e il livello gratuito (10.000 richieste al mese per la maggior parte delle API, 25.000 per la geocodifica) ti permette di testare l'integrazione prima di prendere un impegno.

Domande frequenti

Quando Google deprecherà la Places API legacy?

Google non ha fissato una data di deprecazione definitiva all'inizio del 2026. La API legacy è stata congelata nel marzo 2025 e non riceve più nuove funzionalità. La politica di Google è di fornire almeno 12 mesi di preavviso prima della deprecazione. Tratta la migrazione come urgente, ma non come un'emergenza immediata.

La Places API (New) è più costosa della Places API legacy?

Dipende dal tuo profilo di utilizzo. I nuovi livelli gratuiti per SKU avvantaggiano alcuni profili di utilizzo e penalizzano altri. Mappa le tue chiamate API attuali sulla nuova struttura SKU con i tuoi dati di utilizzo effettivi prima di trarre conclusioni.

Devo migrare anche dalla Directions API?

Sì, se vuoi nuove funzionalità e migliori sconti sul volume. La Directions API e la Distance Matrix API sono state entrambe designate come servizi Legacy nel marzo 2025. Il sostituto è la Routes API, che richiede la propria valutazione di migrazione separata.

Qual è il rischio GDPR di continuare a usare le API di Google Maps come sviluppatore EU?

Google Maps Platform usa infrastrutture statunitensi, il che richiede meccanismi di trasferimento dati transfrontalieri ai sensi del GDPR. La base attuale è il Quadro per la Privacy dei Dati UE-USA, che è già stato contestato legalmente. Per i settori regolamentati, si tratta di un rischio di conformità continuativo che richiede monitoraggio.

Quanto tempo richiede la migrazione verso un fornitore alternativo?

Lo sforzo di ingegneria è simile alla migrazione all'interno di Google: da una a quattro settimane a seconda della complessità dell'integrazione, principalmente dedicato agli aggiornamenti degli endpoint, alle differenze nei parametri e al test dei formati di risposta. I team che usano MapLibre GL JS per il rendering hanno il percorso di migrazione più leggero, poiché il layer di rendering rimane lo stesso.

Conclusione

I cambiamenti di marzo 2025 hanno avviato un conto alla rovescia sull'utilizzo della Places API legacy senza avviarlo ufficialmente. La API funziona ancora. La data di deprecazione non è stata annunciata. Ma la direzione è chiara, e la migrazione sarà meno dolorosa con una pianificazione adeguata che sotto urgenza.

Per gli sviluppatori EU, il momento della migrazione è anche un momento di valutazione. Lo sforzo di ingegneria per cambiare gli endpoint API è in gran parte lo stesso sia che tu rimanga con Google sia che tu passi a un'alternativa ospitata nell'UE. La differenza significativa sta in ciò che porti avanti: il dataset globale completo e le ultime funzionalità di Google, oppure la conformità GDPR by design, prezzi più semplici e residenza dei dati nell'UE.

È una decisione che vale la pena prendere deliberatamente, con dati di utilizzo reali e una visione chiara dei tuoi requisiti di conformità, piuttosto che ricadere per default sul percorso di minore resistenza immediata.

Letture correlate:

• Alternative all'API Google Maps per gli sviluppatori EU
• Guida dello sviluppatore EU alle API di mappe conformi al GDPR
• Prezzi dell'API Google Maps nel 2026: cosa paghi davvero
• Passare dall'API Google Maps: cosa scelgono gli sviluppatori EU
• API di completamento automatico degli indirizzi: come migliora la conversione al checkout