Signed deliveries, and an email that says nothing.

A webhook URL is a secret that leaks. It ends up in a ticket, a Slack message, a screenshot in a handover document, a browser history on a shared laptop. Without a signature, anyone who has seen the URL can post whatever they like to it, and your systems will file it as a genuine consultation response. For a council counting objections to a planning application, that is not a theoretical problem.

So every delivery is signed. Each webhook gets its own randomly generated secret, shown in the builder behind a "show signing secret" control. We compute an HMAC-SHA256 over the exact bytes of the request body using that secret; you recompute it with your copy and compare. A forged request fails, because the forger does not have the secret.

The URL must be https. That is enforced by a database constraint, not a hint in the form, because a signing secret travelling over an unencrypted connection is not a secret.

Verifying a delivery in Node.js

Two details do most of the damage in practice. Use the raw request body, not a parsed and re-serialised object — whitespace differences change the hash. And compare in constant time, so an attacker cannot learn the correct signature one byte at a time from response timings.

import { createHmac, timingSafeEqual } from 'node:crypto';

const SECRET = process.env.NOISSIME_WEBHOOK_SECRET;

// rawBody must be the exact bytes received, before any JSON parsing.
// Re-serialising a parsed object changes the whitespace and the check fails.
function isFromNoissime(rawBody, header) {
  if (typeof header !== 'string') return false;

  const expected =
    'sha256=' + createHmac('sha256', SECRET).update(rawBody).digest('hex');

  const a = Buffer.from(expected);
  const b = Buffer.from(header);

  // timingSafeEqual throws on a length mismatch, so compare lengths first.
  return a.length === b.length && timingSafeEqual(a, b);
}

Call that before you parse anything. If it returns false, answer 401 and discard the request. If it returns true, you have a response that can only have come from your survey.

Add the addresses that should hear about new responses and they are emailed when one arrives. The message is branded HTML with a plain-text alternative, because text-only clients and spam filters both read the plain part. It names the survey, gives the running response total, and links to the results.

What it does not contain is the answers. That is a decision, not an omission. A notification email is forwarded to a colleague, auto-filed into a shared mailbox, synced to a phone and retained in a backup for years. Putting free-text consultation answers into that chain scatters personal data across systems nobody has assessed, and quietly undoes the access controls described on the security page. Respondent data stays in the database, and the email tells you to go and look.

Like webhooks, notifications are fired by a database trigger, so they follow the response rather than a particular submission route. If no addresses are configured, nothing is sent and nothing is attempted.