Modello di integrazione
Architettura inbound e outbound, pattern sincroni e asincroni, garanzie di consegna, idempotenza, backpressure e budget di errore.
Questa pagina definisce come Blu Pantheon e i tuoi sistemi si parlano. Leggila prima di scrivere una riga di codice: le scelte descritte qui determinano affidabilità, costi operativi e facilità di diagnosi dell'integrazione.
I due canali
Inbound — dal tuo sistema verso Blu Pantheon
Il robot, il middleware o il backend aziendale chiama le API REST della piattaforma.
/identity/v1/clientsAPI KeyEsempio di chiamata inbound: elenco paginato dei clienti del progetto.
Caratteristiche:
- Sincrono: la risposta contiene subito il risultato.
- Autenticato con chiave API
bp_live_xxxxxxxxxxxxxxxx. - Soggetto a limiti di frequenza con header
X-RateLimit-Limit,X-RateLimit-Remaining,X-RateLimit-Reset. - Idempotente su richiesta per le scritture, tramite header
Idempotency-Key.
Outbound — da Blu Pantheon verso il tuo sistema
Quando accade un evento, la piattaforma esegue una POST HTTPS verso l'endpoint registrato.
POST /webhooks/blupantheon HTTP/1.1
Host: automation.acme.it
Content-Type: application/json
User-Agent: BluPantheon-Webhooks/1.0
X-BP-Event: session.handover.requested
X-BP-Delivery: 7c1f0f9e-4b2a-4e7c-9a10-2f5c8d3b6a41
X-BP-Timestamp: 1767225600
X-BP-Signature: t=1767225600,v1=9f2c...c41dCaratteristiche:
- Asincrono: l'evento viene consegnato dopo il fatto, non blocca la conversazione.
- At-least-once: la stessa consegna può ripetersi. La deduplica è responsabilità del consumatore.
- Non ordinato: due eventi vicini nel tempo possono arrivare invertiti.
- Firmato: ogni corpo è autenticato con HMAC-SHA256.
Non usare il webhook come transazione
Il webhook notifica che qualcosa è accaduto. Se il tuo processo richiede una risposta che influenza la conversazione in corso, usa una chiamata inbound dal tuo sistema (o uno strumento dell'agente), non la risposta HTTP al webhook.
Flusso completo passo per passo
Scenario: un visitatore chiede di parlare con un operatore, il robot RPA apre un ticket nel gestionale e riporta il numero di pratica nella conversazione.
Il visitatore apre la conversazione
Il widget crea una sessione. La piattaforma emette session.created con sessionId,
projectId e i metadati del canale.
L'agente AI gestisce la richiesta
L'agente risponde usando la knowledge base. Ogni messaggio genera eventi interni; non tutti sono esposti come webhook per evitare rumore.
Viene richiesto l'handover
Il visitatore chiede un operatore umano oppure l'agente rileva un'intenzione critica. La
piattaforma emette session.handover.requested.
Blu Pantheon consegna il webhook
Viene eseguita una POST firmata verso https://automation.acme.it/webhooks/blupantheon.
L'endpoint verifica la firma, controlla X-BP-Delivery contro le consegne già viste, accoda il
messaggio e risponde 202 Accepted in meno di 200 ms.
Il robot preleva il messaggio dalla coda
L'orchestratore RPA assegna il messaggio a un robot disponibile. Il robot legge sessionId,
clientId e la trascrizione sintetica dal payload.
Il robot opera sul gestionale
Il robot apre il gestionale, crea la pratica e ottiene il numero di protocollo
(ad esempio PRT-2026-004512).
Il robot riporta l'esito via API
Il robot esegue una chiamata inbound autenticata per aggiungere una nota alla sessione e
aggiornare i metadati con il numero di pratica. Usa un Idempotency-Key derivato da
X-BP-Delivery per evitare duplicati in caso di riesecuzione.
Chiusura del ciclo
L'operatore vede la nota nella Console. Alla chiusura, la piattaforma emette session.closed
e il robot archivia la pratica.
Sincrono contro asincrono
| Aspetto | Pattern sincrono | Pattern asincrono |
|---|---|---|
| Chi inizia | Il tuo sistema | Blu Pantheon |
| Tempo di risposta | Deve stare nel timeout HTTP del client | L'endpoint risponde subito, il lavoro prosegue in coda |
| Gestione picchi | Il chiamante applica backoff sui 429 | La coda assorbe il picco |
| Errori | Visibili immediatamente | Visibili nei log consegne e nelle metriche della coda |
| Uso corretto | Lettura dati, scritture puntuali, verifiche | Reazione a eventi, orchestrazione di processi lunghi |
Regola pratica
Se l'operazione dura più di 2 secondi, rendila asincrona. Se dura più di 10 secondi, deve obbligatoriamente essere asincrona: il webhook andrebbe in timeout.
Garanzie di consegna
At-least-once
Ogni evento viene consegnato almeno una volta. Una consegna può ripetersi se:
- il tuo endpoint risponde con un codice diverso da
2xx; - la risposta arriva oltre 10 secondi;
- la connessione TCP o il handshake TLS falliscono;
- un operatore esegue un replay manuale dalla Console.
Nessuna garanzia di ordine
Gli eventi non sono ordinati. Non assumere che session.created arrivi prima di
session.message.created della stessa sessione. Per ricostruire l'ordine usa il campo
createdAt del payload, non l'ordine di arrivo.
function shouldApply(incoming, stored) {
if (!stored) return true;
return new Date(incoming.createdAt) > new Date(stored.createdAt);
}Idempotenza
Meccanismi di idempotenza
| Parametro | Tipo | Obblig. | Default | Descrizione |
|---|---|---|---|---|
X-BP-Delivery | string (uuid) | Sì | — | Identificativo univoco della consegna in ingresso. Salvalo e scarta le consegne già viste. |
id | string | Sì | — | Identificativo dell evento nel payload. Stabile tra i ritentativi della stessa consegna. |
Idempotency-Key | string | No | — | Header che invii tu sulle scritture inbound. Ripetendo la richiesta con la stessa chiave ottieni la stessa risposta senza creare duplicati. |
Schema di deduplica consigliato: una tabella con delivery_id come chiave primaria, stato
(received, processing, done, failed) e timestamp. Conserva i record almeno 7 giorni,
cioè oltre la durata massima della catena di ritentativi.
CREATE TABLE bp_webhook_delivery (
delivery_id CHAR(36) NOT NULL PRIMARY KEY,
event_type VARCHAR(64) NOT NULL,
event_id VARCHAR(64) NOT NULL,
status VARCHAR(16) NOT NULL DEFAULT 'received',
received_at DATETIME(3) NOT NULL,
processed_at DATETIME(3) NULL,
INDEX idx_event (event_id),
INDEX idx_status_received (status, received_at)
);Backpressure e code
Il tuo endpoint deve rispondere entro 10 secondi. Se il sistema a valle rallenta, non rallentare la risposta: accoda.
| Componente | Responsabilità | Dimensionamento consigliato |
|---|---|---|
| Listener HTTP | Verifica firma, deduplica, accoda, risponde 202 | Latenza p95 sotto 200 ms |
| Coda | Assorbe i picchi, garantisce persistenza | Capacità pari a 30 minuti di picco |
| Worker / robot | Elabora, ritenta, marca il risultato | Concorrenza limitata dalle licenze RPA |
| Dead letter locale | Raccoglie i messaggi non elaborabili | Allarme su qualsiasi elemento presente |
Antipattern
Elaborare il gestionale dentro la richiesta HTTP del webhook. Il gestionale è lento e instabile: la richiesta andrà in timeout, Blu Pantheon ritenterà, e il gestionale riceverà la stessa operazione più volte in parallelo.
Timeout e budget di errore
| Parametro | Valore | Note |
|---|---|---|
| Timeout di risposta webhook | 10 secondi | Oltre il quale la consegna è considerata fallita |
| Tolleranza timestamp firma | 5 minuti | Oltre la quale la richiesta va rifiutata |
| Tentativi di consegna | 5 | Immediato, 1 min, 5 min, 30 min, 2 h |
| Ritenzione dead letter | 30 giorni | Replay manuale disponibile dalla Console |
| Timeout consigliato lato client inbound | 15 secondi | Con 3 ritentativi e backoff esponenziale |
Definisci un budget di errore esplicito: ad esempio, non più dello 0,5% di consegne fallite su finestra di 24 ore. Superata la soglia, l'integrazione va considerata degradata e va aperta una verifica. Vedi Osservabilità per le metriche.
Webhook, polling o batch?
| Criterio | Webhook | Polling API | Export batch |
|---|---|---|---|
| Latenza | Secondi | Pari all'intervallo di polling | Ore |
| Carico sulle API | Minimo | Alto e costante | Concentrato |
| Complessità iniziale | Media (endpoint pubblico + firma) | Bassa | Bassa |
| Robustezza a disservizi del consumatore | Alta (ritentativi + dead letter) | Alta (riprende da cursore) | Alta |
| Richiede endpoint pubblico | Sì | No | No |
| Ordine garantito | No | Sì, se si usa il cursore | Sì |
| Adatto a riallineamenti storici | No | Sì | Sì |
| Costo per evento | Basso | Alto | Molto basso |
Quando scegliere cosa
- Webhook: reazione in tempo reale a eventi di business. È la scelta predefinita.
- Polling API: quando non puoi esporre un endpoint pubblico (rete chiusa, vincoli di sicurezza), oppure per riconciliazione periodica dopo un disservizio.
- Batch export: per popolamento iniziale, data warehouse, reportistica e analisi storiche.
Combinazione consigliata
Webhook per il tempo reale più un polling di riconciliazione ogni ora sulle ultime 6 ore. Il polling recupera qualunque evento perso senza generare carico significativo.
curl -sS -G "https://api.blupantheon.com/identity/v1/events" \
-H "Authorization: Bearer $BP_API_KEY" \
-H "X-BP-Project: bp_proj_7f3a9c21" \
--data-urlencode "since=2026-09-04T08:00:00Z" \
--data-urlencode "limit=100" \
--data-urlencode "cursor=$LAST_CURSOR"Versionamento del contratto
Ogni payload contiene apiVersion. Le regole di compatibilità sono:
| Tipo di modifica | Considerata | Preavviso |
|---|---|---|
| Aggiunta di un campo opzionale nel payload | Non breaking | Nessuno |
| Aggiunta di un nuovo tipo di evento | Non breaking | Nessuno |
| Rimozione o rinomina di un campo | Breaking | 90 giorni |
| Cambio di tipo di un campo | Breaking | 90 giorni |
| Deprecazione di un evento | Breaking | 180 giorni |
Parsing tollerante
Il tuo consumatore deve ignorare i campi sconosciuti e non fallire se ne compaiono di nuovi. Un parser rigido si rompe alla prima estensione non breaking.