> ## Documentation Index > Fetch the complete documentation index at: https://docs.mattone.co/llms.txt > Use this file to discover all available pages before exploring further. # Canale email · i messaggi Booking.com > Booking.com non ha API messaggi: gli ospiti passano solo via email. Come collegare la casella a Conduit (Gmail OAuth o inoltro), come verificarlo davvero e perché questo step si rompe in silenzio. **Booking.com non ha un'API per i messaggi.** I messaggi degli ospiti arrivano **solo via email**, alla casella registrata nell'Extranet della struttura. Se quella casella non è collegata a Conduit, l'agente **non vede nessun messaggio Booking**. **Questo è lo step che si rompe più spesso, e si rompe in silenzio.** Le **prenotazioni** Booking continuano ad arrivare lo stesso, perché entrano dal PMS (Kross). Sono solo i **messaggi** a mancare. Quindi il cliente non vede nulla di anomalo: lui le mail le riceve nella sua casella e risponde a mano, come ha sempre fatto. Nessuno si accorge che l'AI è cieca su quel canale. È già successo: centinaia di prenotazioni Booking arrivate in mesi e **zero** messaggi mai entrati in Conduit; e un collegamento che ha funzionato una settimana e poi si è staccato senza che nessuno se ne accorgesse per oltre un mese. ## 🔑 La regola che regge tutto **L'indirizzo collegato in Conduit e l'indirizzo nell'Extranet Booking devono essere LO STESSO.** Sembra ovvio, ed è il singolo errore che manda tutto a monte. È già capitato: una **Gmail** collegata e funzionante, poi in Conduit viene collegato il **dominio aziendale** senza completarne la configurazione, e nel frattempo la Gmail viene staccata. Risultato: Conduit puntava a un indirizzo mai finito, Booking scriveva a un altro, e i messaggi sono spariti per settimane senza che nessuno se ne accorgesse. Quando li verifichi o li cambi, **muovili sempre in coppia**: Quello che colleghi a Conduit. Preferibilmente dedicato (`booking@`, `ota@`), non la casella personale. Add Gmail account se è Google, altrimenti inoltro. **Verifica che risulti collegato**, non che sembri collegato. Nelle preferenze notifiche della struttura, come indirizzo che riceve gli avvisi dei messaggi ospite. **Anche se pensi che sia già quello**: confermalo guardando, non a memoria. Se cambi uno dei due senza cambiare l'altro, **il canale muore in silenzio**: le prenotazioni continuano ad arrivare dal PMS e nessuno si accorge che i messaggi non passano più. ## Perché riguarda soprattutto gli studenti Krossbooking Su Kross, Booking.com pesa tipicamente **20-25% delle prenotazioni**. Airbnb entra in Conduit con il suo canale nativo e funziona da subito: è questo che dà la falsa impressione che "l'AI funziona bene". Booking invece passa **solo** da questo canale email. Se lo salti, stai consegnando un agente che copre tre quarti del traffico e ignora il resto. ## Come collegarlo Non è per forza quella che ti dice il cliente, né quella già configurata in Conduit. È l'indirizzo che il cliente ha messo **nell'Extranet Booking**, e va chiesto in modo esplicito: > "Qual è l'indirizzo email a cui ti arrivano le notifiche di Booking? Non quello che usi per scrivere ai clienti: proprio quello dove Booking ti manda gli avvisi dei messaggi degli ospiti." **Non dedurlo dal dominio.** È già successo: il mittente configurato in Conduit era su un dominio aziendale con mail server proprio, e da lì era stato concluso "non ha Google, serve l'inoltro". Falso: la casella che riceveva davvero da Booking era **una Gmail** completamente diversa. Verifica, non inferire. Conduit → **Settings** → **Connected Channels** → **Email** → **Add Gmail account** → login Google e concedi i permessi. L'indirizzo compare sotto *Gmail accounts*, sincronizza i messaggi in entrata e manda le risposte. Niente inoltri, niente codici di conferma, niente DNS. Funziona sia con Google Workspace sia con una Gmail gratuita, e **convive** con un dominio già aggiunto in *Connected domains*: non devi smontare la configurazione esistente. **Su Google Workspace serve un account vero, non un alias.** L'OAuth richiede un login: `booking@` deve essere una casella con una sua password, non un alias che rigira su un'altra. Un account vero **consuma una licenza Workspace** — è un costo piccolo ma va detto al cliente prima, non scoperto a metà procedura. L'indirizzo di ingresso sta in Conduit → **Settings** → **Email** → dominio → sezione **"3. Receiving emails"**: è un indirizzo `...@inbound.postmarkapp.com`. Nel provider del cliente si crea una regola che inoltra lì. Meglio se **filtrata sui mittenti `booking.com`** invece che su tutta la casella: copre `noreply@booking.com`, `no-reply@properties.booking.com` e `-xxxx@guest.booking.com`, e tiene fuori la posta privata. La copia resta comunque nella casella del cliente: non gli sparisce niente. **Prima di tutto: il flag che abilita la notifica in sé.** Extranet Booking → **Struttura** → **Preferenze messaggi**: deve essere **attivo** il flag "ricevi un'email per ogni messaggio inviato dagli ospiti". Se è spento, Booking **non manda nessuna email**, di nessuno dei due tipi qui sotto — non è un problema di contenuto, è proprio zero traffico. Già capitato su più strutture: il canale in Conduit era collegato correttamente, ma questo flag nell'Extranet era disattivato e sembrava un problema di collegamento. Una volta attivo il flag, Booking manda comunque **due tipi di mail diversi**, e uno dei due è inservibile: | Mittente | Contenuto | Utile? | | - | - | - | | `noreply@booking.com` | *"Hai ricevuto un nuovo messaggio. Per leggerlo vai nell'Extranet."* Nessun testo, nessun nome, nessun numero di prenotazione. | ❌ No, non è leggibile nemmeno da un umano | | `-xxxx@guest.booking.com` | Nome ospite, **testo del messaggio**, numero prenotazione, check-in/out, struttura. Rispondibile: Booking gira la risposta all'ospite. | ✅ Sì, è questo che Conduit trasforma in conversazione | Se al cliente arriva il primo tipo, va cambiata la preferenza nell'Extranet perché i messaggi arrivino **col contenuto**. Il link sta dentro la mail stessa ("Modifica le tue preferenze"). ## Verifica: come si controlla DAVVERO **Non fidarti mai della spunta "Inbound email forwarding is set up".** È **auto-dichiarata**, non verificata: la mette a mano chi fa l'onboarding. I record DNS accanto mostrano "Configured" perché Conduit li interroga davvero; quella casella no. Quindi non è una prova: la prova si fa sui dati, come sotto. La verifica vera si fa sui dati, via API o MCP Conduit: 1. **Elenca le conversazioni** del workspace e conta per canale. 2. Devono esistere conversazioni **`unthreaded_email`** con mittente `booking.com` (= le mail entrano) **e** conversazioni **`booking_com`** con messaggi reali (= vengono interpretate). 3. **Zero email in ingresso di qualunque tipo = il canale è morto**, punto. Non serve altra diagnosi. Prima di rifare il collegamento OAuth o l'inoltro, controlla il flag "notifica email per ogni messaggio ospite" nell'Extranet (Struttura → Preferenze messaggi): è la causa più veloce da escludere e la più facile da dimenticare, perché da fuori il canale Conduit sembra collegato bene. Controprova sui contatti: prendi qualche prenotazione Booking e guarda il contatto collegato. Se ha il canale `booking_com` registrato ma **`last_message_at` vuoto** su tutte, non è mai passato un messaggio. **Cosa NON si vede via API:** se il collegamento è OAuth o inoltro. Gli endpoint `/v1/connections` e `/v1/integrations` non esistono (404). L'API dice **se le mail arrivano**, non **come sono collegate**: quella verifica resta in dashboard. ## Dopo averlo collegato: la verifica NON è finita Appena colleghi la casella con **Add Gmail account**, in Conduit cominciano a comparire conversazioni `unthreaded_email` nel giro di pochi minuti. È la prova che l'OAuth funziona — e **non è ancora la prova che il canale Booking funziona**. Misurato su un workspace il giorno del collegamento: prima, centinaia di conversazioni in cinque mesi e **zero** email in ingresso di qualunque tipo. Dopo il collegamento, entro un'ora sono entrate le prime email. Ma erano: * notifiche automatiche del **PMS** (`noreply@krossbooking.com`), * la corrispondenza ordinaria della casella, * **nessuna** email da `booking.com`. **"Arrivano email" ≠ "arrivano le email di Booking".** Le prime mail che vedi entrare sono quelle che la casella riceve di suo: PMS, newsletter, posta personale. Sono la prova che il tubo è aperto, non che ci passi l'acqua giusta. La verifica è completa **solo** quando in Conduit esiste almeno una conversazione con mittente `booking.com` — idealmente una `-xxxx@guest.booking.com` **con il testo del messaggio dentro**. Quindi il collegamento va chiuso così: Se dopo un'ora non è entrato **niente**, l'OAuth non ha funzionato: torna indietro, non aspettare. Devono essere impostate per mandare le notifiche **col contenuto** e all'indirizzo che hai appena collegato. Questo è il passaggio che la gente salta perché "tanto è già collegato". Finché non vedi una mail da `booking.com` dentro Conduit, il canale è **collegato ma non dimostrato**. Segnalo come tale nello stato dell'onboarding, non come "fatto". Nel frattempo si vede anche l'altra faccia della medaglia: le conversazioni che entrano hanno contatti "non mappati", perché sono mittenti che non corrispondono a nessun ospite. È il costo normale dell'OAuth su una casella non dedicata, e la ragione per cui la best practice è un indirizzo `booking@` o `ota@` dedicato. ## Le due trappole Per attivare un inoltro, Gmail manda un **codice di conferma all'indirizzo di destinazione**. La destinazione è la casella Postmark di Conduit, quindi **il codice finisce dentro Conduit** e il cliente non lo vede: si blocca a metà procedura. → Va fatto **in call**, con noi che leggiamo il codice in Conduit e glielo passiamo. Non si delega per iscritto. Vale anche al contrario, come diagnosi: se in Conduit non è **mai** arrivata nessuna email, allora quel codice non è mai stato inviato, quindi **nessuno ha mai nemmeno iniziato** la procedura. Con la strada OAuth il problema non esiste. L'OAuth **sincronizza l'intera casella**. Se lo colleghi su un indirizzo personale, dentro Conduit finisce anche la posta privata del cliente. Successo davvero: su un workspace sono entrate notifiche di calendario, di riunioni, del revenue tool, di Google, corrispondenza personale e persino le nostre mail di marketing. Su un altro, l'inoltro di tutta la casella è stato **spento dopo una settimana** — plausibilmente proprio per questo. **Best practice: indirizzo dedicato** (`booking@`, `ota@`), mai la casella di corrispondenza personale. È lo standard nostro: La forma è sempre la stessa: una casella dedicata sul dominio del cliente, del tipo `booking@` o `ota@`, usata solo per le OTA. L'elenco di quali clienti usano quale casella sta nel repo interno, non qui. **Consenso esplicito.** Collegare una casella significa che l'AI vede quella posta. Su un indirizzo dedicato è irrilevante. Su una casella personale **va detto e concordato col cliente prima di collegarla**, non nascosto in mezzo a un'istruzione tecnica. ## Se le mail arrivano ma le conversazioni non nascono Se vedi le `unthreaded_email` da Booking ma **nessuna** conversazione `booking_com`, il collegamento è a posto e il problema è a valle: 1. Verifica di essere nel caso della mail **col contenuto** (tabella sopra). Se arrivano solo gli avvisi vuoti, non c'è niente da interpretare: si torna alle preferenze dell'Extranet. 2. Se il contenuto c'è ed è completo, è il parser di Conduit → **apri ticket** allegando l'esempio esatto: mittente, oggetto, data e testo della mail. *** ## Checklist finale * [ ] Sai qual è la casella **vera** dell'Extranet Booking (chiesta, non dedotta) * [ ] **L'indirizzo collegato in Conduit e quello nell'Extranet sono lo STESSO** (verificato guardando entrambi) * [ ] Nell'Extranet, **Struttura → Preferenze messaggi**, il flag di notifica email per ogni messaggio ospite è **attivo** * [ ] È collegata: **Add Gmail account** se Google, altrimenti inoltro all'indirizzo Postmark * [ ] L'Extranet manda le notifiche **col contenuto**, non gli avvisi vuoti * [ ] Se è una casella personale: consenso del cliente **esplicito** * [ ] In Conduit esistono conversazioni `unthreaded_email` da `booking.com` * [ ] In Conduit esistono conversazioni `booking_com` **con messaggi reali** * [ ] Hai fatto un test con un ospite Booking vero Finché manca l'ultima riga, lo stato corretto è **"collegato, non dimostrato"** — non "fatto". This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.