200 messages per account per day. That's the free-plan send ceiling on a Nylas Agent Account, and it's a surprisingly useful number to design an outreach agent around — it forces the kind of pacing that keeps cold email from becoming spam, and paid plans drop the daily cap by default when you outgrow it.

The bigger idea: instead of sending campaigns through a rep's mailbox or a send-only API, the agent gets its own address. sales-agent@yourcompany.com is a real mailbox — it sends, it receives replies, it owns a calendar. Agent Accounts are in beta, but the model is straightforward: each account is just another grant, so the Messages, Threads, Events, and Webhooks endpoints you'd use for a connected Gmail account work unchanged.

What the loop looks like

The sales-outreach pattern from the product docs runs in three stages, all on one grant_id:

1. Send the campaign through the standard send endpoint.
2. Classify replies with an LLM into interested / not now / unsubscribe, threading every exchange through the Messages API.
3. Book the meeting — when a prospect says yes, the same grant creates an event on the agent's own calendar and sends the invite.

No CRM hand-offs between three tools, no rep mailbox cluttered with sequence noise.

Replies arrive as webhooks

Inbound mail fires message.created, and the payload looks exactly like it does for any other grant. One subscription covers your whole application:

curl --request POST \
  --url 'https://api.us.nylas.com/v3/webhooks/' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer <NYLAS_API_KEY>' \
  --data-raw '{
    "trigger_types": ["message.created", "event.created", "event.updated"],
    "description": "Outreach agent",
    "webhook_url": "https://your-app.example.com/webhooks/nylas",
    "notification_email_addresses": ["dev-team@your-company.com"]
  }'

Your endpoint gets a GET with a challenge query parameter first — echo it back in a 200 and deliveries start flowing as POSTs. The payload's data.object carries sender, recipients, subject, snippet, and the field that matters most here: thread_id, which groups the whole back-and-forth into one conversation your classifier (and your CRM) can reason about.

Two handler habits from the pipeline recipe are worth copying verbatim. First, respond with a 200 immediately and do the real work after — slow handlers trigger Nylas retries, which means more duplicates to dedup. Second, verify the signature before trusting anything in the body:

const crypto = require("crypto");

function verifyWebhookSignature(req, webhookSecret) {
  const signature = req.headers["x-nylas-signature"];
  const hmac = crypto.createHmac("sha256", webhookSecret);
  const digest = hmac.update(JSON.stringify(req.body)).digest("hex");
  return signature === digest;
}

An outreach agent acts on what webhooks tell it. A forged message.created that skips verification is a forged instruction to your agent.

The unglamorous parts that decide whether this works

The sales pipeline automation recipe is blunt about where these systems fail, and every lesson transfers directly to an outreach agent:

Webhooks are at-least-once. The same message.created notification can land twice, especially if your handler was slow. Track processed webhook IDs in Redis or a database table with a TTL — an in-memory Set doesn't survive restarts. An outreach agent that double-processes a reply is an agent that replies twice.

Out-of-office replies fire message.created like real replies. Detect them with subject patterns (out of office, automatic reply, auto-reply) and skip. An OOO classified as "interested" pollutes your pipeline worse than a missed reply.

Use the folders field for direction. A message in SENT is the agent's own outbound; INBOX means the prospect wrote back. Don't compare addresses against a roster — check the folder.

Skip internal mail. If every address on a message belongs to one of your company's domains, it's colleagues talking — not pipeline signal. Compare sender and recipient domains against your own and bail early, or your activity log fills up with "lunch?" threads.

Filter automated senders. no-reply@, notifications@, mailer-daemon@, postmaster@, bounce@ — none of these are prospects, and a bounce treated as engagement is how an agent emails a dead address forever. The recipe also flags the List-Unsubscribe header and "unsubscribe" in the subject as bulk-sender tells.

const noReplyPatterns = [
  /^no-?reply@/i,
  /^notifications?@/i,
  /^mailer-daemon@/i,
  /^postmaster@/i,
  /^bounce@/i,
];
if (noReplyPatterns.some((p) => p.test(senderEmail))) return;

Closing the loop on the calendar

This is the piece send-only infrastructure can't replicate. When the classifier returns interested and the prospect agrees to a time, the agent creates the event on its own primary calendar with notify_participants=true. The invite goes out from the agent's address as a normal calendar invitation; the event.created and event.updated webhooks in the subscription above tell you when the prospect accepts. The same recipe's advice applies here too: key CRM records on the event id, because meetings get rescheduled constantly and event.updated will fire for every change.

For longer deal cycles, replies can arrive days after the last touch. The multi-turn conversation pattern — send, receive, restore context from the thread, respond — is built for exactly that, and the thread history doubles as the record of everything the agent ever told a prospect.

Why not just use the rep's inbox?

You can connect rep mailboxes over OAuth, and for logging human activity into a CRM that's the right call — the pipeline recipe does precisely that with message.created and event.created across connected grants. But campaign sends from a rep's address mean the rep's sender reputation absorbs the campaign's bounces, the rep's inbox absorbs the replies, and offboarding the rep breaks the integration. A dedicated agent identity isolates all three. You can even provision one agent per customer domain — sales-agent@customer-a.com, sales-agent@customer-b.com — each with its own quota and reputation, all in one application.

Quick answers

Do I need one webhook per agent? No — a single subscription covers every grant in your Nylas application, agents and connected rep accounts alike. Branch on the grant's provider ("nylas") to tell agent deliveries apart from connected-grant deliveries.

What about contact data? Reply classification gets you intent; the pipeline recipe pairs it with a nightly job that pulls contacts from the Contacts API (paginated 50 at a time with next_cursor) and patches fresh phone numbers, job titles, and companies into the CRM. Real-time webhooks for activity, periodic sync for data that rots slowly.

If you want to test the shape of this without committing, provision an account on a trial *.nylas.email domain, point the webhook at a tunnel, and run a five-prospect campaign against your own test addresses. The classification step is where the interesting tuning lives — what label set are you using for reply intent? I'd genuinely like to hear what taxonomies are working for people in the comments.