Webhooks and freshness

How do you find out something changed? Xero notifies you about four categories — contacts, invoices, credit notes and subscriptions. QuickBooks notifies you about most. NetSuite does not notify you at all. None of them sends the data — every notification is an instruction to go and fetch.

Concepts: 7
Divergences: 3
Structural: 1
Volatility: Verify the numbers

Endpoints

Xero

Webhooks: Invoices, Contacts, Credit notes, Subscriptions

x-xero-signature, HMAC-SHA256

QBO

Webhooks across most entities

intuit-signature, HMAC-SHA256

NetSuite

None

User event script callout, or poll

The same concept in three vocabularies

Read across a row. Where a cell is absent, the concept has nowhere to live in that system — which is a design constraint, not a gap to paper over.

Native: — A field or object exists for it
Partial: — Exists with a caveat that changes what you can build
Derived: — Not stored — you compute it
Absent: — Nothing in the API

Webhooks and freshness fields compared across Xero, QuickBooks Online and NetSuite
Concept	Xero	QBO	NetSuite
Available at all	Four event categories Invoices, Contacts, Credit notes (added 2026), and app Subscriptions	Most entities	None Script it yourself
PayloadNone of the three sends the record.	Resource ids and event type	Entity name, id and operation CloudEvents envelope (e.g. qbo.invoice.updated.v1) — mandatory migration from the legacy eventNotifications shape by 15 May 2026	Whatever your script sends
Signature	x-xero-signature HMAC-SHA256 over the raw body	intuit-signature HMAC-SHA256	Yours to design
Endpoint validation	Intent to receive Fail it and the endpoint is disabled	Verifier token	—
Delivery guarantee	Retries, then disables	Retries with backoff	Yours
Deletes notified	As an update to a voided record	Operation: Delete / Void / Merge	Only if you script it
Practical freshness	Seconds for the notified entities; your poll interval for the rest	Seconds	As often as you poll

What actually differs, and what you do about it

A difference stated without a response is trivia. Each of these carries the handling.

Sharp edge

Every webhook is a notification, not a feed

Xero · QBO

You receive 'invoice X changed' and must fetch the invoice. That fetch counts against the same rate limit as everything else, so a burst of webhooks during a bulk edit in the ledger's own UI can exhaust your minute budget and delay everything else.

Do — Enqueue notifications, coalesce duplicates for the same record, and fetch through the same limiter as the rest of the sync. Never fetch inline in the webhook handler — return 2xx first.

Sharp edge

Xero disables an endpoint that fails validation

Xero

The intent-to-receive handshake must succeed before any business logic runs: Xero sends signed and deliberately mis-signed requests and expects 200 and 401 respectively, within five seconds. A slow or failing endpoint gets turned off rather than retried indefinitely. A deployment that breaks the signature check silently stops all notifications.

Do — Verify the signature and return 2xx within the timeout, before any processing. Monitor for the absence of webhooks as an alarm condition — silence looks identical to nothing happening.

Structural

NetSuite has no webhooks

NetSuite

The substitutes are a user event SuiteScript that calls out on save — which puts your endpoint's availability in the path of the customer's ability to save a record — or scheduled polling on lastmodifieddate.

Do — Poll by default. Offer the script only where the customer's own team maintains it, and never let a callout block a save.

The same fact, different payloads

Stacked rather than tabbed — a reader comparing two shapes should not have to hold one of them in memory.

Xero — verify first, enqueue second, fetch later

Xero

const expected = createHmac("sha256", XERO_WEBHOOK_KEY)
  .update(rawBody, "utf8").digest("base64");

// Constant-time compare, before anything else touches the body.
if (!timingSafeEqual(Buffer.from(expected),
                     Buffer.from(req.headers["x-xero-signature"]))) {
  return new Response(null, { status: 401 });
}

await queue.push(JSON.parse(rawBody).events);   // ids only
return new Response(null, { status: 200 });     // within the timeout

What this changes in the interface

The payoff. Every difference above that reaches the surface, and what the component does about it.

Freshness varies by source and by entity: The connection panel states the mechanism and the age per source: webhooks for QBO invoices, hourly polling for NetSuite. Users plan around it when they can see it.
Notifications can stop silently: The absence of events is monitored and surfaced. A connection that has heard nothing for longer than expected shows as stale, not as healthy.

Where the accounting is explained

DocSystem states

What consumes this payload

The normalised object above is what the components read. These are the surfaces it feeds, the words for the concepts in it, and the document that explains the accounting.

Compared acrossXero docs QuickBooks Online docs NetSuite docsVerify quantitative claims

Endpoints

The same concept in three vocabularies

What actually differs, and what you do about it

Every webhook is a notification, not a feed

Xero disables an endpoint that fails validation

NetSuite has no webhooks

The same fact, different payloads

What this changes in the interface

Where the accounting is explained

What consumes this payload

Get your books closed every month