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.

Subscribe once

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.

The handler's three jobs

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

1. Verify the HMAC signature. Compute SHA-256 over the raw body with your webhook secret and compare against the x-nylas-signature header. Skip this and anyone who finds your URL can inject fake tickets.
2. Respond 200 fast, process async. A slow response counts as a failed delivery and triggers retries — which means duplicate processing of the very message you were slowly processing.
3. Refetch when truncated. Messages over 1 MB arrive as 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.

Classification without an ML team

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.

Delivery semantics you must respect

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.

Close the loop with the sender

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.

Prove it before real mail arrives

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?