> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bubblav.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Cloudflare Email

> Connect Cloudflare Email Service to route inbound support email into your unified BubblaV inbox, with threaded replies sent through the Cloudflare API and AI-drafted responses from Copilot

Bring your support emails into the same BubblaV inbox as your live chat, Messenger, WhatsApp, and other channels. Connect Cloudflare with an API token and a from-address on your Cloudflare domain — inbound mail is forwarded through Cloudflare Email Routing into BubblaV, triaged alongside everything else, and you reply by email directly from the dashboard with the original thread intact.

## Why Connect Cloudflare Email?

<CardGroup cols={2}>
  <Card title="One Unified Inbox" icon="inbox">
    Triage chat, social DMs, and email conversations in a single place
  </Card>

  <Card title="Reply by Email" icon="reply">
    Agent replies are sent through the Cloudflare Email Sending API and thread correctly in the customer's mail client
  </Card>

  <Card title="API-Native" icon="bolt">
    No IMAP/SMTP credentials or app passwords — just an API token and your Cloudflare account ID
  </Card>

  <Card title="Two Inbound Paths" icon="route">
    Zero-code: forward your support address to a BubblaV-hosted inbound address. Advanced: deploy a lightweight Email Worker on your own domain
  </Card>
</CardGroup>

<Note>
  The Cloudflare Email channel creates a support conversation your team owns. The AI doesn't auto-send email replies — but Copilot can **draft** every reply for you. See [Draft a Reply with Copilot on Email](#draft-a-reply-with-copilot-on-email) below.
</Note>

## Prerequisites

* A **Cloudflare account** with your domain on it.
* A **Cloudflare API token** with Email Sending permission — steps below.
* Your **Cloudflare account ID** — steps below.
* A **from-address on a domain onboarded to Cloudflare Email Sending** — e.g. `support@yourdomain.com`. Cloudflare Email Sending must be enabled for the domain that owns the address.
* **Email Routing enabled** on your domain (**Email → Email Routing**) for inbound delivery.

### Getting your API token

<Steps>
  <Step title="Open API Tokens">
    In the Cloudflare dashboard, click your profile icon → **My Profile** → **API Tokens** tab → **Create Token**.
  </Step>

  <Step title="Create a Custom Token">
    Scroll to the bottom and choose **Create Custom Token → Get started**. Give it a name like `bubblav-email`.
  </Step>

  <Step title="Set permissions">
    Under **Permissions**, add a row: **Account** → **Email Sending** → **Edit**. (Edit covers both sending mail and reading the suppressions list BubblaV uses to validate your token at connect.)
  </Step>

  <Step title="Scope and create">
    Under **Account Resources**, select your account (or **All accounts** if you manage several). Leave TTL/IP filters blank unless your security policy requires them → **Continue to summary** → **Create Token**.
  </Step>

  <Step title="Copy the token">
    The token is shown **once** — copy it now and keep it handy for the connect dialog.
  </Step>
</Steps>

### Getting your account ID

Your account ID is a 32-character hex string. Two easy ways to find it:

* **Overview page**: click any domain in the dashboard — the account ID is in the **right-hand sidebar** under the API section, next to Zone ID.
* **URL**: open any domain — the address bar shows `https://dash.cloudflare.com/<account-id>/<zone-id>`; the first ID is your account ID.

## Setup Steps

<Steps>
  <Step title="Open the Cloudflare Email integration">
    In your dashboard, go to **Integrations** and find **Cloudflare Email** under the Communication category.
  </Step>

  <Step title="Enter your credentials">
    Paste your Cloudflare API token, account ID, and the support address replies should be sent from — for example `support@yourdomain.com`.
  </Step>

  <Step title="Connect">
    BubblaV validates the token and account, then opens the **configure page** showing your unique inbound address — it looks like `cf-xxxxxxxx@inbound.bubblav.se`.
  </Step>

  <Step title="Set up inbound delivery">
    Choose one of the two inbound paths below.
  </Step>
</Steps>

## Inbound — Option A: forward to your BubblaV address (recommended)

The configure page shows a unique inbound address `cf-<token>@inbound.bubblav.se`. Point your Cloudflare Email Routing at it:

<Steps>
  <Step title="Add the destination address first">
    In the Cloudflare dashboard → your domain → **Email → Email Routing → Destination Addresses** (also reachable from the Routing Rules screen via **Manage destination addresses**), click **Add destination address** and enter your minted `cf-<token>@inbound.bubblav.se` address. Until it's added **and verified**, it won't appear in the routing-rule dropdown.
  </Step>

  <Step title="Wait for the verification email">
    Cloudflare immediately sends a confirmation email **to the `cf-<token>` address** — and because that address is hosted by BubblaV, the verification email lands in your **BubblaV inbox as a normal conversation**.
  </Step>

  <Step title="Click the link in the ticket">
    Open the conversation in **Live Support** (it typically arrives from `no-reply@cloudflare.com` with a subject about address verification) and click the verification link. The destination address now shows **Verified**.
  </Step>

  <Step title="Create the routing rule">
    Back in **Email → Email Routing → Routing Rules**, create a rule (a custom address like `support@`, or a catch-all) with action **Forward to** → select your now-verified `cf-<token>@inbound.bubblav.se` from the destination dropdown → save. Real mail starts flowing into the inbox.
  </Step>
</Steps>

<Tip>
  If the verification ticket doesn't show up within a couple of minutes: check your **Archived** conversations, make sure `no-reply@cloudflare.com` isn't on your **Ignored Senders** list, and resend the verification from Cloudflare's destination-address screen.
</Tip>

## Inbound — Option B: self-hosted Email Worker (advanced)

If you'd rather keep inbound traffic entirely inside your own Cloudflare account, deploy the small ingest worker on your domain:

<Steps>
  <Step title="Deploy the worker">
    Click **Deploy to Cloudflare** on the configure page (or clone `bubblav-org/cloudflare-email-worker`), then set the `BUBBLAV_TOKEN` secret to the token shown on your configure page: `npx wrangler secret put BUBBLAV_TOKEN`.
  </Step>

  <Step title="Route mail to it">
    In **Email → Email Routing → Email Workers** (or a Routing Rule with the action **Send to a Worker**), bind your support address to the deployed worker.
  </Step>

  <Step title="Done">
    The worker forwards raw email to your BubblaV endpoint — no destination-verification step is needed for this path.
  </Step>
</Steps>

### Recipient filter

Use the **Allowed addresses** list (in the connect dialog, or later on the configure page) to ingest only mail sent to addresses you list — e.g. `support@yourdomain.com` — and keep `noreply@` notifications out. Blank = accept mail addressed to any address on your domain (the default). The **Ignored Senders** blocklist still applies on top.

## Managing Your Integration

* **New mail** arrives shortly after delivery to your routed address and appears as a conversation in **Live Support**, tagged with a Cloudflare Email badge.
* **Reply** from the conversation view — your reply is sent through the Cloudflare Email Sending API from your connected address and threaded under the customer's original email.
* **Auto-reply, signature, and filters**: the configure page exposes the same email settings — enable AI auto-replies, set a reply signature, manage allowed addresses and ignored senders.
* **Change credentials**: disconnect and reconnect with the new details — your inbound `cf-<token>` address stays the same, so your routing rule never breaks.
* **Disconnect** from the integration's configure page. Nothing remote is removed — delete the Cloudflare routing rule yourself when you're done.

## How Replies Are Threaded

Each reply includes the correct `In-Reply-To`, `References`, and `Re:` subject headers so it lands inside the customer's existing email conversation in Gmail, Outlook, Apple Mail, and other clients — rather than starting a new thread.

## Draft a Reply with Copilot on Email

You don't have to write every reply from scratch. On any email conversation in the unified inbox, click **Draft reply with Copilot** and BubblaV writes a complete draft straight into your composer.

<Steps>
  <Step title="Open the email conversation">
    In **Live Support**, open the email ticket you want to answer.
  </Step>

  <Step title="Click Draft reply with Copilot">
    Copilot reads the customer's email (including attachments) and writes a complete, source-cited draft based on your knowledge base and the customer's context.
  </Step>

  <Step title="Review and personalize">
    Check the draft, adjust the tone, and add anything Copilot couldn't know.
  </Step>

  <Step title="Send">
    Your reply goes out through the Cloudflare API from your connected address, threaded under the customer's original email — exactly as if you'd written it yourself.
  </Step>
</Steps>

<Info>
  Copilot only drafts — a human always reviews and sends. Nothing goes out from your address without an agent clicking send.
</Info>

## Troubleshooting

<AccordionGroup>
  <Accordion title="Connect says my Cloudflare credentials are invalid">
    Check the API token has **Email Sending** permission and is scoped to the right account, and that the account ID is copied exactly (32-hex string from the domain Overview page).
  </Accordion>

  <Accordion title="The routing rule is created but mail never arrives">
    Confirm you clicked the verification link — the rule stays inactive until the `cf-<token>` destination is verified. The verification email lands as a conversation in your BubblaV inbox. If it didn't, resend it from the destination-address screen in Cloudflare.
  </Accordion>

  <Accordion title="Mail arrives for some addresses but not others">
    Check your **Allowed addresses** list on the configure page — when it's non-empty, only listed To/Cc addresses are ingested. Also confirm the sender isn't on **Ignored Senders**.
  </Accordion>

  <Accordion title="Replies fail with a sender-verification error">
    The from-address domain must be onboarded to **Cloudflare Email Sending**. Onboard the domain in the Cloudflare dashboard (Email → Email Sending) and try again.
  </Accordion>

  <Accordion title="Replies aren't threading in the customer's mail client">
    Threading relies on the `In-Reply-To` and `References` headers carried from the inbound email. If a conversation was started manually rather than from an inbound email, the first reply starts a new thread by design.
  </Accordion>
</AccordionGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.