Monitor a Support Inbox and Open Tickets Automatically

Before: a customer emails "production is down" at 11pm, the message sits unread until someone opens the shared inbox at 8am, gets forwarded to the wrong team at 9, and reaches on-call by 10. After: the webhook fires within moments of arrival, keyword rules tag it as an incident, the sender's domain bumps the priority, and on-call gets paged while the customer is still typing their follow-up.

The difference is one webhook subscription and a handler. The inbox monitoring recipe builds that handler end to end, and it's provider-agnostic — the same code serves Google, Microsoft, and IMAP mailboxes. Run it against an Agent Account (beta) and the support address itself is provisioned by your app, with the same message.created

events and the option to acknowledge the sender from the very mailbox that received the ticket.

curl --request POST \
  --url 'https://api.us.nylas.com/v3/webhooks/' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer <NYLAS_API_KEY>' \
  --data '{
    "trigger_types": ["message.created"],
    "description": "Support ticket monitor",
    "webhook_url": "<YOUR_WEBHOOK_URL>",
    "notification_email_addresses": ["you@example.com"]
  }'

Immediately after creation, a GET

hits your endpoint with a challenge

query parameter. You must echo back the raw value — no JSON wrapping — in a 200 response within 10 seconds, or the webhook stays inactive with no retry. That challenge handshake is the single most common "why isn't my webhook working" answer.

Every notification needs the same treatment before any business logic runs:

x-nylas-signature

header. Skip this and anyone who finds your URL can inject fake tickets.message.created.truncated

with the body stripped, on the same subscription you already have. Detect the suffix (or the missing body

) and fetch the full message from the API.The recipe's routing is deliberately boring: keyword lists mapped to categories, plus a sender-domain check.

const CATEGORY_RULES = [
  { keywords: ["urgent", "down", "outage", "critical", "broken"],
    category: "incidents", priority: "high" },
  { keywords: ["bug", "error", "crash", "not working", "issue"],
    category: "bugs", priority: "medium" },
  { keywords: ["billing", "invoice", "charge", "refund", "payment"],
    category: "billing", priority: "medium" },
  { keywords: ["feature", "request", "suggestion", "would be nice"],
    category: "feature_requests", priority: "low" },
  { keywords: ["cancel", "unsubscribe", "close account"],
    category: "churn_risk", priority: "high" },
];

const HIGH_PRIORITY_DOMAINS = ["bigcorp.com", "enterprise-client.io"];

function processMessage(message) {
  if (isAutoReply(message)) return;

  const searchText =
    `${message.subject || ""} ${message.body || ""}`.toLowerCase();

  let category = "general";
  let priority = "low";
  for (const rule of CATEGORY_RULES) {
    if (rule.keywords.some((kw) => searchText.includes(kw))) {
      ({ category, priority } = rule);
      break;
    }
  }

  // Known enterprise senders jump the queue regardless of category
  const senderDomain = (message.from?.[0]?.email || "").split("@")[1];
  if (HIGH_PRIORITY_DOMAINS.includes(senderDomain)) priority = "high";

  routeTicket({
    messageId: message.id,
    from: message.from?.[0]?.email,
    subject: message.subject,
    category,
    priority,
    receivedAt: new Date(message.date * 1000).toISOString(),
  });
}

Anything unmatched falls through to a general queue at low priority, so nothing gets dropped. It's fifty lines you can fully predict and unit-test, and the structure leaves an obvious seam for swapping in an LLM classifier later without touching the webhook plumbing. The ticket that comes out the other end routes to whatever you already use: Jira, Zendesk, a database table, a Slack channel.

The underrated half of classification is exclusion. Out-of-office replies, bounces, and delivery notifications would otherwise open a ticket every time a customer goes on vacation. The recipe's filter checks headers first, subject patterns second:

function isAutoReply(message) {
  const headers = message.headers || {};

  if (headers["auto-submitted"] && headers["auto-submitted"] !== "no") return true;
  if (headers["x-auto-response-suppress"]) return true;
  if (["bulk", "junk"].includes(headers["precedence"])) return true;

  const subject = (message.subject || "").toLowerCase();
  return [
    "out of office",
    "automatic reply",
    "delivery status notification",
    "undeliverable",
    "mail delivery failed",
  ].some((phrase) => subject.includes(phrase));
}

Also check the message's folders

array — your own team's sent mail and synced drafts fire message.created

too, and a ticket monitor that files your outbound replies as new tickets is a special kind of feedback loop. Skip anything whose folders include SENT

or DRAFTS

, along with calendar invitation notifications and anything sent from your own support address.

Notifications are at-least-once. The same message.created

can arrive twice, usually because your first response was slow. Track processed message IDs — the recipe suggests Redis with a 24-hour TTL — and skip duplicates; an in-memory set dies with the process. And when a burst of mail triggers a burst of full-message fetches, throttle them: the recipe's queue waits 100ms between API calls to stay clear of rate limits.

One non-obvious detail about truncation: you don't subscribe to message.created.truncated

separately. Nylas sends it automatically on the same subscription whenever a message crosses the 1 MB threshold — large attachments and rich HTML newsletters do this constantly — so your handler has to expect both shapes from day one, not as a later hardening pass.

A ticket system that swallows email silently makes customers re-send "did you get this?" follow-ups, which open more tickets. Once the ticket is created, send an acknowledgment from the same mailbox that received it — "we got your message, your ticket is #1234, here's what happens next." With an Agent Account this is one send call against the same grant, and the customer's eventual reply threads back into the mailbox your handler already watches. Just make sure your auto-reply filter and the sent-folder check are in place first, or your own acknowledgment becomes the next inbound ticket.

There's a dedicated test endpoint — POST /v3/webhooks/send-test-event

with "trigger_type": "message.created"

— that sends a mock payload to your URL, confirming reachability and signature verification with zero real email involved. Then send yourself something with "urgent: database down" in the subject and watch it route.

Spin up the handler, run the test event, and time the path from send to ticket. If it's under a minute, you've already beaten every human triage rotation. What's the actual median time-to-triage in your support inbox today — and have you ever measured it?