QuickBooks webhooks deliver, but the payload parses as empty

The endpoint is being called. The HMAC signature verifies. You return 200. And nothing downstream happens, because the code reads a root key that is no longer there. This failure is silent by construction: every check that would have alerted you still passes.

QBO: the Reports API serves only modernized v2 responses since Sept 1, 2026; webhooks are CloudEvents since Jul 31, 2026.

What changed

QuickBooks Online webhook payloads are wrapped in CloudEvents envelopes. Intuit's migration deadline for this was July 31, 2026 — moved out from an earlier date of May 15, 2026 — and the migration is complete. This is the current payload format, not an upcoming change, so “we will do it before the deadline” is no longer the situation you are in.

The specific breakage: code that looks for a top-level eventNotifications root finds nothing. Delivery and signature verification are unaffected, so no error is raised and no alarm fires — the handler simply processes zero notifications, forever, while the queue behind it stays empty and the sync quietly falls behind.

How to tell this is what you have

Webhook deliveries are arriving (your access log or Intuit's delivery view shows them) and your endpoint is returning 2xx.
Signature verification passes.
Your parsed notification count is zero, or the field you read comes back null or undefined, and the last successful event predates the cutover.
Nothing in your deploy history lines up with when it stopped.

Log one raw request body, unparsed, and look at the root keys. That single log line settles it faster than any other check.

What to do right now

Update the parser to read the CloudEvents envelope — its type, its source, and the data payload that carries the realm and the entity notifications — rather than assuming the old root shape. The notification content you were already handling is inside that envelope; the routing around it is what has to change.
Check the SDK version you have pinned. Older QuickBooks SDK versions parse against the legacy shape and will misparse or silently drop data. This applies to Intuit's .NET SDK, node-quickbooks-style Node packages and python-quickbooks-style Python packages alike; a stale pin in a lock file, requirements.txt or package.json is the usual cause, not the application code.
Add an alert on the thing that was silent. A processed-notification count of zero over a period where deliveries arrived is the signal that would have caught this on day one. It is worth adding now, because the next payload change will be just as quiet.
Then check your Reports API calls. The same integration is very likely affected by the other QuickBooks cutover. Reports have been v2-only since Sept 1, 2026.

Then scan the code

DeadlineScan is a free, MIT-licensed command-line scanner. It flags code that parses QuickBooks webhook payloads assuming the legacy eventNotifications-root shape, and it flags QuickBooks SDK references so you can check the pinned versions. It makes no network calls and sends no telemetry, so your code never leaves the machine.

deadlinescan scan ./my-repo

Get the scanner: email hello@deadlinescan.com and you'll get the source and a Windows binary by reply — the public repository is being prepared.

A finding count of zero means no affected call sites were FOUND — not that you're unaffected.

That line carries extra weight here. The QuickBooks rules have never been run against a real QuickBooks codebase — the five repositories in the published validation audit are all EWS — so a clean report on a QuickBooks integration is a starting point for your own review, not a certificate. The validation numbers, in full.

Sources