Nylas for customer support

Support teams need three things from email: incoming messages turned into tickets fast, the right humans paged for the urgent ones, and routine replies handled without a person typing every word. The Nylas Email and Webhooks APIs cover the first two, and AI agents on top of the inbox cover the third. The sections that follow pair each of those jobs with the products that cover it, flag where provider differences bite, and show the terminal commands to prototype with before you drop into a full tutorial.

The model is the same whether you run a five-seat startup help desk or a large contact center. A connected mailbox becomes a stream of events, each event becomes a ticket or a routing decision, and a draft sits in front of an agent for one click of approval. You connect one mailbox per account through a single OAuth grant, then read and write against the Email API using one schema across Google, Microsoft 365, Yahoo, iCloud, IMAP, and Exchange. Six providers, one set of fields, so your ticket logic doesn’t fork per vendor.

How do you turn inbound email into tickets in real time?

You turn inbound email into tickets by subscribing to message webhooks and creating a ticket the moment a message.created event lands, instead of polling the mailbox on a timer. Webhooks push events to your endpoint within seconds, which keeps first-response time low and avoids the cost of listing 50 messages per page just to find the one new email. That latency difference is the whole reason support teams move off polling.

The flow is a single subscription. Register a webhook against /v3/webhooks pointed at your handler URL, list the available event types with nylas webhook triggers, and your handler turns each payload into a ticket. Before you ship the handler, fire a test event so you can confirm the shape of the payload without waiting for a real customer email.

# Discover trigger types, then create the subscription
nylas webhook triggers
nylas webhook create --url https://support.example.com/hooks/nylas --triggers message.created

# Send a synthetic event to validate your handler
nylas webhook test send https://support.example.com/hooks/nylas

For local development, the CLI tunnels a public URL straight to your laptop so you can debug the handler before any cloud deploy. Run nylas webhook server --port 4000 --tunnel cloudflared --secret <webhook-secret> and point a temporary subscription at the tunnel address. When you outgrow a single HTTP endpoint and need fan-out or replay, switch the delivery channel to Google Pub/Sub with nylas webhook pubsub create --topic projects/my-project/topics/support-events --triggers message.created, backed by the /v3/channels/pubsub channel. Pub/Sub buys you durability: if your ticketing service is down, the messages queue instead of dropping.

The full listener, including the ticket-creation logic and dedupe, lives in the tutorial below.

Build with Nylas

Direct integration patterns for support inboxes, covering monitoring, routing, and scheduled comms. Each tutorial below builds on the same connected mailbox, so the email read and write calls behave identically across all 6 providers: Google, Microsoft 365, Yahoo, iCloud, IMAP, and Exchange. One schema covers all of them, which means a ticketing flow you prove against one mailbox runs unchanged against the remaining providers, and you don’t rewrite the integration per vendor.

Tutorial	Products	What you’ll build
Monitor an inbox for support tickets	Email, Webhooks	A real-time listener that detects support requests and creates tickets from incoming email
Schedule reminders from calendar events	Calendar, Email	Email notifications before customer appointments
Automate customer onboarding	Email, Calendar, Scheduler	Welcome sequences, kickoff call scheduling, and engagement tracking

How do you route and prioritize support messages?

You route support messages by reading each one as it arrives, scoring it against rules or a model, and tagging it so the right queue or person picks it up. Listing endpoints return 50 messages per page by default and up to 200 with limit, with cursor pagination through page_token, so a backfill of an existing inbox is bounded and predictable. Real-time routing, though, works off the webhook event, not a list scan.

Routing reads happen against GET /v3/grants/{grant_id}/messages. The fields you route on are consistent across all six providers: sender, subject, snippet, and which thread the message belongs to. A common first pass is keyword and sender matching, with anything ambiguous handed to an AI triage agent that buckets the message by urgency. Mark the urgent ones starred so they surface at the top of every agent’s view.

# Pull the latest messages, then flag the high-priority one
nylas email list
nylas email mark starred <message-id>
nylas email mark unread <message-id>

When you need to find every open conversation about a single customer or topic, query instead of scroll. nylas email search "subject:refund" runs against the same message store and returns matches you can pipe into a routing rule. Keep the routing keyed to the thread so a follow-up reply lands in the same queue as the original ticket. The list, search, and mark endpoints are documented under the Email API overview.

The decision worth making early is where the routing logic lives. You can run it inline in the webhook handler, which keeps latency low but couples your scoring to the delivery path, or you can write a lightweight tag to the message and let a separate worker pick up the routing. The second shape scales better once volume grows, because the handler only has to acknowledge the event quickly and a worker reads in pages of up to 200 messages on its own schedule. Either way, the same five fields drive every decision, so the rules you write don’t change when a customer switches from one of the six supported providers to another.

How do you draft support replies with a human in the loop?

You draft support replies by generating a reply into a saved draft and leaving the send action to a person. A draft is a real object you create through POST /v3/grants/{grant_id}/drafts. It sits in the mailbox unsent until an agent reviews and approves it, which is the safety gate that keeps an automated system from emailing a customer the wrong thing. None of the agent tutorials below send automatically. Every one drafts and waits.

To reply in context, pull the thread first so the model and the agent both see the full back-and-forth, not just the latest line. GET /v3/grants/{grant_id}/threads returns the conversation, and the CLI shows it inline. A single thread can run long, and the message list it draws from returns up to 200 messages per page with limit, so even a drawn-out support case loads without truncating the history the agent reasons over.

# Read the whole conversation, then stage a reply for review
nylas email threads list
nylas email threads show <thread-id>
nylas email drafts create --to [email protected] --subject "Re: your order"

The draft sits in the same mailbox the customer is already talking to, so when an agent hits send it threads correctly and the customer never sees a separate “no-reply” address. This human-in-the-loop pattern is the core of the AI agent recipes below.

A practical reason to draft rather than send is that the cost of a wrong reply is asymmetric. A delayed answer annoys a customer, but an incorrect or off-tone automated answer can lose them. Staging the reply lets a person catch the rare bad generation while still saving the typing on routine replies, and because the access token behind the grant refreshes every 3,600 seconds without your code touching it, a draft an agent prepared overnight is still valid when a person reviews it in the morning. The draft object is the same across every provider, so the review queue your team works from looks identical whether the original message came in over Gmail or Exchange.

Nylas for AI Agents

AI agents for support inbox triage, draft generation, and long-running customer threads. These recipes read the inbox in pages of up to 200 messages, score each one, and stage a draft for review, so an agent works a backlog without a person opening every message first. The grant they run on refreshes its access token automatically every 3,600 seconds, which is what lets a triage agent run on a cron schedule for days with no re-auth step wedged into the loop.

Tutorial	Products	What you’ll build
Build an email support agent	Email	KB-backed support drafts with confidence gates and risk tiering. Human-in-the-loop, never sends automatically
Build an AI email triage agent	Email	cron-driven triage into urgent, action, informational, and noise; drafts automatically for the top two buckets
Reach inbox zero with an AI agent	Email	Interactive five-minute triage; agent sorts, drafts, archives, you approve
Support agent over multi-day threads	Agent Accounts, Email	Maintain conversation context across days of back-and-forth without losing the plot

How do you schedule appointment reminders for support cases?

You schedule appointment reminders by reading upcoming events off the connected calendar, then sending a reminder email a fixed window before each one. Many support cases end with a scheduled callback, an onsite visit, or a demo, and a no-show wastes the slot. Pulling the next several days of events with GET /v3/grants/{grant_id}/events gives you the list to remind against. The default reminder job runs over the next 7 days of events.

The read is one command. List the events, filter to the ones with a customer attendee, and queue a reminder email through the same Email API you already use for replies.

# List the next week of calendar events to remind against
nylas calendar events list --days 7

Because the reminder send reuses the email send path, the customer gets the message from the same support address that handled their ticket, which keeps the conversation in one place. The end-to-end reminder build, including the timing logic and the email template, is in the schedule reminders from calendar events tutorial. For the calendar primitives themselves, see the Calendar API overview.

Run support workflows from the terminal with the Nylas CLI

The CLI mirrors the Email, Webhooks, and Calendar APIs across all 6 providers, which is enough to run a full support loop from a shell script or a cron job with no application server in between. You can list and search the inbox, stage drafts, mark priority, and manage webhook subscriptions, all without writing a line of integration code first. This is the fastest way to prototype a routing rule or test a webhook before you commit to a service.

A representative end-to-end loop reads new mail, flags the urgent message, pulls its thread, and stages a reply for a human to approve.

# A support triage loop, start to finish
nylas email list
nylas email search "subject:urgent"
nylas email mark starred <message-id>
nylas email threads show <thread-id>
nylas email drafts create --to [email protected] --subject "Re: your case"

Add --json to most commands and the output becomes machine-readable, so you can pipe it into jq and drive downstream logic. Every command shown here has a documented reference at Nylas CLI commands. The CLI authenticates with the same grant your application uses, so a workflow you prove out in the terminal maps directly onto the API calls you ship.

Things to know about support integrations

Support integrations live or die on delivery guarantees and provider quirks, so plan for both before you go live. The points below are the constraints that most often surprise teams building their first ticketing or triage flow.

Webhook delivery and retries. Webhooks are at-least-once, not exactly-once, so your handler must be idempotent. Dedupe on the message ID before creating a ticket, or a single email can spawn two tickets after a retry. Validate every payload against the signature before you trust it, and return a 200 quickly so the platform doesn’t mark your endpoint as failing. For the durability you need under load, route through Pub/Sub with /v3/channels/pubsub so events queue instead of dropping when your service restarts. The webhook best practices guide covers signature verification and retry handling in depth.

Token refresh. OAuth access tokens expire after 3,600 seconds, and the platform refreshes them automatically, so a long-running listener won’t suddenly lose access mid-shift. You don’t manage the refresh yourself. You do need to handle the rarer case where a customer revokes the grant, which surfaces as an auth error your handler should catch and surface to an admin rather than retry forever.

Page size and backfill. List endpoints return 50 messages per page by default and a maximum of 200 with the limit parameter, paginated with page_token. For real-time work you rely on webhooks and never page at all. Paging only matters for the initial backfill of an existing inbox or for a search sweep, and even then you should bound it so a large mailbox doesn’t run your job for hours.

Threading across providers. A reply created as a draft and sent through the mailbox threads correctly because it stays in the same conversation the customer started. Thread identifiers are consistent within the unified schema, so your routing can key a follow-up to its original ticket regardless of whether the customer is on Gmail or Microsoft 365. Read the thread before you draft so the reply has the full context.

Folders versus labels. Google uses labels, where one message can carry several, while Microsoft and most IMAP providers use folders, where a message lives in exactly one place. If your routing moves tickets between states by changing where they sit, that difference changes the result. Don’t hardcode folder names either, because organizations rename and localize them. The folders and labels reference explains the mapping the API normalizes for you.

What’s next

• Email API overview: read, send, and manage email
• Webhooks overview: real-time event notifications
• Folders and labels: manage email organization
• Webhook best practices: reliable webhook processing
• Calendar API overview: events for appointment reminders
• Nylas CLI command reference: every CLI command documented