Quando un report Power BI deve dialogare con un gestionale, un portale web o una pipeline dati, le API diventano il ponte tra l’analisi e il resto dell’azienda. Il tema power bi api riguarda però più di una semplice chiamata HTTP: comprende automazione, sicurezza, aggiornamento dei modelli semantici e interrogazione dei dati con DAX.
Le idee essenziali per usare Power BI in modo programmabile
- Le API REST permettono di gestire report, workspace, modelli semantici, refresh ed embedding.
- DAX e API lavorano insieme quando un’applicazione deve interrogare un modello Power BI e ricevere risultati strutturati.
- L’autenticazione passa da Microsoft Entra ID, con token delegati o identità applicative.
- Il limite JSON è di 100.000 righe, 1.000.000 di valori e 15 MB per query.
- La sicurezza richiede permessi Build, gestione corretta dei segreti e attenzione alla RLS.
Che cosa permettono davvero le API di Power BI
Le API di Power BI sono interfacce che consentono a un’applicazione di eseguire operazioni sul servizio senza passare ogni volta dall’interfaccia grafica. In pratica, si possono pubblicare report, elencare workspace, avviare aggiornamenti, generare token per l’embedding e recuperare informazioni sui modelli semantici.
Questa distinzione è importante perché spesso si parla di “API di Power BI” come se esistesse un unico strumento. In realtà ci sono gruppi di endpoint dedicati a contenuti, amministrazione, embedding, refresh, gateway e dataset, oggi chiamati sempre più spesso modelli semantici.
Automazione operativa
Un caso comune è il refresh automatico dopo il caricamento di un file o la chiusura di un processo contabile. Un’applicazione può verificare lo stato dell’aggiornamento, leggere la cronologia degli errori e inviare una notifica solo quando il modello non è pronto.
Per me è uno degli usi più concreti delle API. Automatizzare un refresh non rende il modello migliore, ma elimina attività ripetitive e riduce il rischio che qualcuno dimentichi di aggiornare un report prima di una riunione.
Embedding e applicazioni personalizzate
Con l’embedding, un report o una dashboard può essere visualizzato dentro un portale aziendale, un’applicazione per clienti o un prodotto SaaS. L’utente non deve necessariamente aprire il portale Power BI, ma l’accesso deve essere regolato da token e permessi coerenti.
Qui le API non servono solo a mostrare un grafico. Gestiscono il ciclo completo, dalla scelta del report alla generazione del token, fino all’applicazione dei filtri e alla sicurezza dei dati visualizzati.
Il rapporto tra API e DAX
DAX è il linguaggio con cui Power BI calcola misure, colonne calcolate e query analitiche. Le API, invece, sono il canale attraverso cui un programma può chiedere al modello di eseguire una query e restituire il risultato.La differenza tra misura e query DAX evita molti equivoci. Una misura come [Vendite Totali] definisce una logica riutilizzabile nel modello; una query DAX usa istruzioni come EVALUATE per produrre una tabella di risultati che un’applicazione può leggere.
{
"queries": [
{
"query": "EVALUATE SUMMARIZECOLUMNS('Calendario'[Anno], \"Vendite\", [Vendite Totali])"
}
],
"serializerSettings": {
"includeNulls": true
}
}In questo esempio l’API non restituisce un grafico, ma una tabella con anno e vendite. È un dettaglio decisivo: il programma ricevente deve sapere come trasformare quel risultato in JSON, tabella, file o componente visuale.
La query deve restituire una tabella
L’endpoint JSON per l’esecuzione delle query lavora con una query per chiamata e una sola tabella di risultato. La struttura più affidabile parte da EVALUATE e usa funzioni come SUMMARIZECOLUMNS, SELECTCOLUMNS e FILTER per limitare ciò che viene restituito.
Una query come EVALUATE VALUES('Prodotti'[Categoria]) è adatta a ottenere un elenco di categorie. Una query che prova a restituire un modello intero è invece una scelta sbagliata, perché aumenta il payload, rallenta l’esecuzione e può superare rapidamente i limiti del servizio.
Il contesto di filtro resta fondamentale
DAX non è SQL con nomi diversi. Il risultato dipende dal contesto di filtro, cioè dall’insieme di filtri e relazioni che influenzano il calcolo. Se una query viene costruita senza considerare relazioni, calendario o filtri di sicurezza, il valore restituito può essere formalmente corretto ma analiticamente inutile.
Prima di esporre una misura tramite API, controllo sempre il suo comportamento in Power BI Desktop. Se il numero non è affidabile nel report, non diventerà più affidabile perché viene richiesto da Python o da un servizio web.
Come impostare un’integrazione funzionante
Un’integrazione solida segue un percorso abbastanza lineare, ma ogni passaggio ha una conseguenza pratica. Saltare la configurazione dei permessi è il modo più rapido per ottenere errori 401 o 403 difficili da diagnosticare.
- Registrare un’applicazione in Microsoft Entra ID e scegliere se usare accesso delegato o identità applicativa.
- Concedere gli scope necessari, per esempio permessi di lettura o lettura e scrittura sul modello semantico.
- Abilitare l’impostazione tenant che autorizza l’esecuzione delle query, quando si usa l’endpoint dedicato.
- Assegnare i permessi Power BI all’utente o al service principal, incluso il permesso Build sul modello quando richiesto.
- Ottenere un token OAuth 2.0 e inserirlo nell’header Authorization della richiesta.
- Inviare la query DAX con l’identificativo corretto del modello e verificare sia lo status HTTP sia il corpo della risposta.
Il service principal è comodo per processi server-to-server perché non dipende da un dipendente che deve fare login. Non va però trattato come una scorciatoia universale: Microsoft Learn segnala limitazioni importanti quando il modello usa Row-Level Security o Single Sign-On.
Un esempio minimale in Python
import requests
headers = {
"Authorization": f"Bearer {access_token}",
"Content-Type": "application/json"
}
payload = {
"queries": [
{
"query": """
EVALUATE
SUMMARIZECOLUMNS(
'Calendario'[Anno],
"Ricavi", [Ricavi Totali]
)
"""
}
]
}
response = requests.post(endpoint, headers=headers, json=payload)
response.raise_for_status()
data = response.json()Il codice è volutamente semplice. In produzione aggiungerei timeout, logging, gestione dei retry e una validazione dello schema ricevuto, perché un modello può cambiare nome a una colonna o a una misura senza che l’applicazione se ne accorga immediatamente.
Quale endpoint scegliere per le query DAX
Per l’esecuzione di DAX esistono due approcci principali. Il primo restituisce risultati in JSON ed è più facile da consumare con applicazioni tradizionali, strumenti low-code e flussi di Power Automate. Il secondo utilizza il formato Apache Arrow, pensato per analisi ad alte prestazioni e librerie colonnari come pandas, Polars e Spark.
| Caratteristica | Endpoint JSON | Endpoint Arrow |
|---|---|---|
| Formato | JSON leggibile e semplice da integrare | Flusso binario colonnare |
| Capacità | Utilizzabile anche con Pro e PPU, secondo configurazione e permessi | Richiede un modello su capacità Premium, Fabric o Embedded |
| Uso ideale | Dashboard applicative, automazioni e piccoli result set | Pipeline analitiche e grandi volumi |
| Vantaggio principale | Compatibilità con quasi ogni linguaggio | Tipi più fedeli e deserializzazione più efficiente |
La scelta non dipende solo dalla velocità. Se il consumer sa leggere esclusivamente JSON, il formato Arrow non è una soluzione pratica. Se invece i dati devono finire in un dataframe e il risultato supera qualche centinaio di righe, Arrow riduce il lavoro di conversione e gestisce meglio i tipi numerici e temporali.
Microsoft Learn indica inoltre che l’endpoint JSON ha limiti precisi per ogni query. Il risultato non può superare 100.000 righe, 1.000.000 di valori o 15 MB, a seconda del limite raggiunto per primo, e il servizio applica un tetto di 120 richieste al minuto per utente.
Limiti, sicurezza ed errori da evitare
Il primo errore è confondere l’accesso al report con l’accesso ai dati. Un utente può riuscire a vedere una pagina e non avere il permesso Build necessario per interrogare il modello tramite API. Il risultato tipico è un errore 403, anche quando l’identificativo del report sembra corretto.
Non usare l’API come strumento di esportazione massiva
Le query DAX via REST sono adatte a risultati mirati, come KPI, aggregazioni e tabelle filtrate. Non sono il canale giusto per scaricare ogni riga di un modello operativo. Per grandi estrazioni conviene lavorare sulla sorgente dati, su una pipeline dedicata o su un’architettura Fabric progettata per quel volume.
Una buona regola pratica è selezionare solo le colonne necessarie e aggregare prima di trasferire i dati. Restituire cinque colonne invece di venti può fare la differenza tra una risposta rapida e un payload che supera i limiti.
Gestire token e segreti con attenzione
Il token non deve mai essere inserito nel codice sorgente, in un file condiviso o nel browser. Va conservato in un secret manager e rinnovato secondo la sua scadenza. In un’architettura web, il browser dovrebbe parlare con un backend controllato, non chiamare direttamente Power BI con credenziali sensibili.
Per la Row-Level Security, la richiesta deve mantenere il corretto contesto dell’utente. Un’identità applicativa configurata male può esporre più dati del previsto oppure fallire perché il modello usa una modalità di autenticazione non supportata.Interpretare correttamente le risposte
Un codice HTTP 200 non significa sempre che la query abbia prodotto il risultato desiderato. La risposta può contenere un errore a livello di query o una tabella limitata. Per questo verifico sempre il contenuto di results, tables e degli eventuali oggetti error.
Gli errori 400 indicano spesso una query DAX non valida, una struttura non supportata o un risultato oltre i limiti. Gli errori 401 riguardano in genere token mancanti, scaduti o destinati alla risorsa sbagliata; i 403 segnalano più spesso autorizzazioni insufficienti.
Tre scenari in cui l’integrazione porta valore
KPI nel portale commerciale
Un portale per la rete vendita può richiedere tramite API il fatturato del mese, il margine e il numero di clienti attivi. Il modello Power BI mantiene le misure DAX centralizzate, mentre il portale mostra solo i valori necessari per ogni agente.
Il vantaggio è la coerenza. La formula del margine non viene riscritta in JavaScript o in cinque applicazioni diverse, ma resta nel modello governato da Power BI.
Controllo automatico degli aggiornamenti
Un processo notturno può avviare il refresh, attendere il completamento e notificare il team in caso di errore. In questo scenario le API gestiscono lo stato operativo, mentre DAX entra in gioco per validare alcuni indicatori dopo il caricamento.
Per esempio, un controllo può verificare se il totale delle vendite è nullo o se l’ultimo giorno disponibile è troppo vecchio. È un piccolo controllo di qualità che spesso intercetta problemi prima degli utenti finali.
Leggi anche: Esempi di Power BI e DAX per decisioni aziendali migliori
Analisi in Python senza duplicare tutta la logica
Un data scientist può interrogare il modello semantico e ricevere aggregazioni già calcolate, invece di ricostruire in Python tutte le regole aziendali. Questo funziona bene per analisi esplorative, purché il volume sia compatibile con il formato scelto e con i limiti dell’endpoint.Non lo userei come sostituto di un data warehouse. Lo considero piuttosto un modo efficace per riutilizzare metriche certificate quando servono risultati analitici coerenti con i report aziendali.
Il criterio che uso per decidere se partire
Le API di Power BI hanno senso quando esiste un’esigenza precisa di integrazione o automazione. Se l’obiettivo è soltanto condividere un report con colleghi autorizzati, l’interfaccia del servizio è spesso sufficiente e aggiungere codice crea complessità senza un beneficio reale.
Prima di sviluppare, definisco quattro elementi: chi accede, quali dati servono, con quale frequenza e in quale formato. Da queste risposte dipendono autenticazione, endpoint, capacità necessaria e struttura delle query DAX.
La combinazione più equilibrata, nella maggior parte dei progetti, è un modello semantico ben progettato, misure DAX testate e un piccolo servizio backend che espone solo i risultati necessari. È meno spettacolare di una grande integrazione costruita in fretta, ma regge meglio quando aumentano utenti, dati e requisiti di sicurezza.
