Letterbook Docs
Get tickets into Letterbook
Choose the right inbound channels for email, API-created tickets, Discord, and AI-assisted intake.
Last updated June 25, 2026
What this guide covers#
Ticket ingestion is the set of channels that create conversations in Letterbook. A channel might be an email address, a Gmail mailbox, an API endpoint, a Discord server, the user portal, or another integration.
Use this guide when you are deciding which customer entry points should create Letterbook tickets, which setup path each channel should use, and how to avoid duplicate conversations.
Start with where customers already ask for help#
Before configuring channels, list every place customers currently contact your team:
- Public support addresses, such as
support@company.com,help@company.com, orbilling@company.com - Shared Gmail or Google Workspace mailboxes
- Google Groups, aliases, distribution lists, or Microsoft 365 shared addresses
- Website contact forms and in-app support forms
- Mobile app support flows
- Discord support forums, threads, or channels
- Existing helpdesk addresses that still receive new mail
- Escalation addresses used by high-value customers, partners, or internal teams
Then decide whether each source should become a Letterbook conversation. Some channels should create tickets automatically. Others should stay informational, private, or internal.
Channel decision checklist#
Use one primary ingestion path for each customer-facing source.
| Customer source | Best Letterbook path | Use it when |
|---|---|---|
| Existing support email | Forwarding address | The address is hosted anywhere, is an alias or group, or is currently routed through another system |
| Dedicated Gmail mailbox | Gmail integration | The support address is a real Gmail or Google Workspace mailbox that can be authorized directly |
| App, website, or backend event | Letterbook API | Your product already has structured customer context and should create tickets server-side |
| Customer community | Discord integration | Support starts in Discord forums, threads, or monitored channels |
| Branded help center | User portal | Customers should search docs first and submit a ticket only when self-service does not solve the issue |
| Conversational source with mixed chatter | AI turn detection | Not every message should become a ticket, so Letterbook should identify support-worthy turns |
The main rule is simple: a customer message should have one path into Letterbook. If the same message arrives through forwarding, Gmail, and an old helpdesk at the same time, your team will see duplicate tickets.
Email#
Email is usually the first channel to connect because customers already know the address and reply threading matters.
Letterbook supports two practical email paths:
- Forwarding: your current email provider forwards inbound messages to a Letterbook-generated address.
- Gmail: Letterbook connects directly to a Gmail or Google Workspace mailbox.
Both create conversations from customer email. The difference is how Letterbook receives the message and what kind of access you need to grant.
Forwarding#
Use forwarding when the customer-facing address should stay exactly the same but mail needs to flow into Letterbook.
Forwarding is the most flexible email setup. It works well for:
- Non-Gmail providers
- Microsoft 365 or Outlook-hosted support addresses
- Google Groups
- Aliases that do not have their own mailbox login
- Distribution lists
- Previous helpdesks that still receive inbound mail
- Multiple addresses that should land in one Letterbook inbox
The flow is:
customer -> support@company.com -> current mail destination -> Letterbook forwarding address -> Letterbook conversation
Forwarding is an inbound routing setup. It does not, by itself, authorize Letterbook to send replies from your domain. If customers should receive replies from support@company.com, also configure sending and DKIM in Enable sending from your support address.
Choose forwarding when you want minimal mailbox access, when the address is not a dedicated Gmail mailbox, or when you are migrating from another helpdesk and need a controlled handoff.
Read the full setup guide: Set up forwarding addresses.
Gmail#
Use the Gmail integration when the support address is a real Gmail or Google Workspace mailbox and your team can authorize Letterbook to connect directly to it.
The flow is:
customer -> Gmail or Google Workspace mailbox -> Letterbook Gmail integration -> Letterbook conversation
Gmail is a good fit when:
- Your team already handles support from Gmail.
- The support address has its own mailbox.
- The mailbox owner can complete the Google authorization flow.
- Your Google Workspace admin can approve the app if required.
- You prefer a direct Google connection instead of maintaining forwarding rules.
Use forwarding instead when the address is a Google Group, alias, distribution list, or migrated helpdesk route. Those sources are often easier and cleaner to forward than to connect as a mailbox.
Read the full setup guide: Connect Gmail.
Forwarding versus Gmail#
| Area | Forwarding | Gmail integration |
|---|---|---|
| Provider coverage | Works with almost any provider that can forward mail | Gmail and Google Workspace only |
| Access model | Letterbook receives forwarded messages | Letterbook connects directly to the Google mailbox |
| Best for | Aliases, groups, migrations, shared addresses, non-Gmail providers | Dedicated Gmail or Google Workspace support inboxes |
| Setup owner | Whoever controls forwarding rules | Whoever can authorize the mailbox, plus admin approval if required |
| Main risk | Duplicate routing, forwarding loops, sender rewriting | Wrong mailbox authorization, Workspace approval, duplicate routing if forwarding is also enabled |
Do not leave both forwarding and Gmail active for the same mailbox unless you intentionally want duplicate ingestion for testing. In production, pick one.
API-based ingestion#
Use the Letterbook API when the ticket starts inside your product, backend, website, or internal system.
API-based ingestion is best when the source already has structured data that should travel with the support request:
- Customer ID
- Account or workspace ID
- Plan, subscription, or entitlement data
- App version, device, or operating system
- Current page, feature, or workflow
- Error details, logs, or reproduction steps
- Internal priority or escalation reason
The flow is:
customer action -> your server -> Letterbook API -> Letterbook conversation
Send API requests from your server. Do not expose Letterbook API keys in browsers, mobile apps, or client-side bundles. Client-side forms and mobile apps should call your backend first, and your backend should authenticate to Letterbook.
Use API ingestion when:
- You are building an in-app "contact support" flow.
- You want a website form to create a ticket without relying on email delivery.
- Your backend detects an issue and should open a support conversation.
- You need reliable metadata attached to the first message.
- You want to link a Letterbook conversation back to a customer account or internal object.
Read the API guides:
Other integrations#
Use native integrations when customers already ask for help in a place that is not email and not your own product UI.
Discord#
Use the Discord integration when your community is an active support surface. This is common when customers ask questions in forums, channels, or threads before they ever email support.
The flow is:
customer Discord post or thread -> monitored Discord surface -> Letterbook Discord integration -> Letterbook conversation
Discord is a good channel when:
- Your users already expect support in your Discord server.
- Support questions happen in forum posts or threads.
- Your team needs community context preserved in the support workflow.
- Replies should sync back to Discord instead of moving the customer to email.
Be selective about which Discord surfaces create tickets. Monitoring every channel can create noisy tickets from casual discussion, bug speculation, or internal chatter. Start with dedicated support forums or channels, then add more surfaces once your team understands the volume.
Read the full setup guide: Connect Discord.
AI turn detection#
Use AI turn detection for channels where not every message should become a ticket.
Some sources are conversational. A customer might post several messages, ask a product question, react to another user, or add context later. In those environments, creating a ticket for every message creates noise. AI turn detection helps identify the moments that should become support work.
Use AI turn detection when:
- The channel has a mix of support requests and general conversation.
- A ticket should start only when a customer asks for help.
- Follow-up messages should attach to the existing conversation instead of creating new tickets.
- The team wants Letterbook to reduce intake noise before triage.
Turn detection should still be tested like any other ingestion path. Send realistic examples that include clear support requests, casual discussion, follow-up context, and edge cases. Confirm that support-worthy turns become conversations, non-support messages stay out of the queue, and follow-ups attach to the right ticket.
After tickets are created, configure AI reply behavior in Configure AI replies and routing behavior in Triage and assignment.
Recommended launch sequence#
- Connect the main support email address first.
- Send realistic test tickets through forwarding or Gmail.
- Configure sending and DKIM before replying from your branded address.
- Add API ingestion for product-native forms or mobile support flows.
- Add Discord only for the channels where customers already expect support.
- Enable AI turn detection for noisy conversational sources.
- Test every channel with one happy path, one follow-up, one attachment or metadata example, and one duplicate-risk example.
Production checklist#
Before going live, confirm that:
- Every customer-facing source has exactly one ingestion path.
- Old helpdesk routes and auto-replies are disabled if they would create duplicates.
- Customer identity is preserved on the conversation.
- Replies thread back into the same conversation.
- Attachments or metadata arrive where expected.
- The right team can triage, assign, and reply.
- Sending is verified for any email address customers will see.
- AI behavior is reviewed on realistic examples before unattended use.