Detecting bot opens and clicks in Nuntly webhooks

You send a verify email during customer onboarding through Nuntly. A second later, email.opened fires on your webhook. The recipient hasn't opened anything: an automated scanner did.

Nuntly still counts the open and still sends the webhook, exactly as before, now with isBotEvent telling you this one was probably not a person. That alone proves nothing, but it keeps a scanner-triggered open from being read as a real signal in your onboarding funnel.

That's not an isolated glitch. Corporate security scanners fetch every link before delivery, and privacy features prefetch images automatically, on every email you send. None of it is malicious, and until now, none of it was visible: every automated open or click landed in your dashboard indistinguishable from a real one.

Why your open and click data was never fully human

Bot traffic in email engagement data means opens and clicks generated by mail infrastructure, security tools, or client software, rather than by a person reading the email. It has shadowed open tracking since pixel tracking itself became common, and it got worse with each round of client-side privacy features.

Three sources account for most of it:

• Apple Mail Privacy Protection (MPP). Since iOS 15 and macOS Monterey, Apple lets Mail users route image loading through a proxy, so a tracking pixel loads before the recipient ever opens the message. According to Litmus's Email Client Market Share report, which tracks over a billion opens a month across its Email Analytics customers, Apple Mail's overall share of opens reached 62% in July 2026, with MPP estimated to affect roughly 55-60% of all email opens (Litmus, Email Client Market Share, July 2026). Treat that figure as a third-party measurement, not an Apple-published number.
• Corporate email security gateways. Tools like Proofpoint, Mimecast, and Microsoft Defender for Office 365 scan every link in an inbound email before it reaches the recipient (Microsoft Learn, Safe Links overview), which fires your click-tracking event before anyone has read the message.
• Antivirus and link-preview bots. Some mail clients and security extensions generate a request to every link in an email to check it against a threat database.

Apple states the MPP mechanism directly:

Your IP address is hidden from senders and remote content is privately downloaded in the background when you receive a message (instead of when you view it).

Source: Apple, Mail Privacy Protection support page

All three sources predate isBotEvent and aren't disappearing. They're just now labeled. What changed is that Nuntly can now tell you, per event, which bucket it likely falls into.

What isBotEvent actually tells you

isBotEvent: an optional field on the email.opened and email.clicked webhook payloads with two possible values, Likely or Unlikely, indicating whether that specific open or click was probably automated rather than a genuine human interaction.

It shows up nested inside the event's existing open or click object, next to the fields you already read:

{
  "id": "evt_01k4v3s0k8yq0e7f2c1a3d8e01",
  "type": "email.opened",
  "createdAt": "2026-09-13T09:12:04.000Z",
  "data": {
    "id": "em_01k4v3s0k8yq0e7f2c1a3d8e00",
    "messageId": "01020193fa2fe1fa-1a2b3c4d-5e6f-7890-abcd-ef0123456789-000000",
    "domainName": "yourdomain.com",
    "from": "hello@yourdomain.com",
    "to": "recipient@example.com",
    "subject": "Welcome to Nuntly",
    "sentAt": "2026-09-13T09:11:58.000Z",
    "enqueuedAt": "2026-09-13T09:11:57.000Z",
    "open": {
      "openedAt": "2026-09-13T09:12:04.000Z",
      "userAgent": "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) AppleWebKit/605.1.15",
      "isBotEvent": "Unlikely"
    }
  }
}

A few details matter more than the field itself:

• It is optional, not nullable. When no signal is available, isBotEvent is omitted from the payload entirely. It never appears as "isBotEvent": null. Your parsing logic should treat this as three distinct states: absent, Likely, or Unlikely, not a binary bot/not-bot flag.
• It is a likelihood, not a verdict. Likely means the signal that produced the event looked automated. It is not a confirmed bot flag, and Nuntly does not claim certainty either way.
• No setup required. If open or click tracking is already enabled on your sending domain, the field starts appearing on new events automatically.
• Nothing retroactive. Events recorded before this shipped read as absent, same as any value Nuntly doesn't recognize. Nothing gets backfilled or guessed.

Using isBotEvent in your webhook handler

The field is additive. If your handler does not read it, nothing changes. If you do read it, the pattern that works best is tagging, not filtering:

app.post('/webhooks/email-events', async (req, res) => {
  const event = req.body;

  if (event.type === 'email.opened') {
    const isBot = event.data.open.isBotEvent === 'Likely';

    await db.emailEvent.create({
      emailId: event.data.id,
      type: 'opened',
      openedAt: event.data.open.openedAt,
      isBotEvent: isBot,
    });

    if (!isBot) {
      await crm.markProspectEngaged(event.data.id);
    }
  }
});

Store the flag on every event, then use it downstream: exclude Likely opens from an "engaged leads" report, or wait for an Unlikely open before triggering a sales follow-up. Filtering happens in your application, on data you control, which means you can change your mind about the threshold without losing anything.

What isBotEvent does not do

• It never changes what gets counted. Every open and click event is counted and every webhook is queued the same way regardless of the signal. isBotEvent is metadata on an event that already happened, not a filter on whether it happens.
• Security and fraud detection aren't its job. A Likely click does not mean the recipient's account is compromised. It means a scanner or a prefetcher probably touched the link first.
• Only opens and clicks carry it. Deliveries, bounces, and complaints do not get this field. Those events are not affected by prefetching or link-scanning in the first place.
• Some events won't carry it at all. Not every notification includes a signal. Build your handler to treat "absent" as its own case, not as Unlikely.

Cleaner engagement data, same reliable webhooks

isBotEvent doesn't clean up your open rate. It just tells you which opens were never a real signal to begin with.

Check the webhook events guide for the full payload reference, or read how Nuntly's webhooks handle retries and event replay if you have not set up tracking yet.