For Stakeholders

Why this PR exists

Dentolize's webhook integration (API Config) is how third-party systems stay in sync with clinic data without polling. It already covered patients, invoices, payments, treasuries, procedures, operations, expenses, and expense payments. Patient balance — money added directly or credited from an overpayment — was the one financial event type it didn't cover. For any clinic reconciling patient money in an external system, that was a silent gap: balance could move without the integration ever knowing.

This PR closes that gap (NEW_BALANCE_INVOICE, NEW_BALANCE_PAYMENT) and does two pieces of cleanup along the way: it removes an unused three-way "Type" selector on the webhook config form (all three options behaved identically, so it was pure surface area with no function), and it fixes two data-correctness bugs in the payload/response — one where insurance policyholder names were always sent as blank, one where a balance invoice's reference number could be written onto the wrong invoice.

Risk and blast radius

Low risk, narrow blast radius. This entire feature is behind a company-level flag (apiEnabled) that is off by default and only enabled for clinics actively using webhook integrations — the change is invisible to the vast majority of clinics. Within enabled clinics, the change only affects integration payloads and one settings form field; no patient-facing or invoicing behavior changes. Webhook delivery failures don't block or roll back the underlying action (handleCallApi swallows its own errors), so there's no new failure mode that could interrupt a clinic's ability to add balance or take a payment.

What to watch after this ships

• Clinics with an active API Config integration should confirm their

receiving system correctly ignores unrecognized event types until they explicitly opt in to the two new ones — no action needed on Dentolize's side, but worth a heads-up to integration partners.

• If any clinic relied on the removed NPHIES / ZATCA type label for

something outside Dentolize (unlikely, since it changed nothing in the payload), that would be worth knowing about — but the code shows no behavioral difference existed to depend on.

Open gap worth flagging

Webhook delivery has no logging, retry, or alerting — a fact that predates this PR but is worth stakeholder awareness of, since this PR adds two more event types riding on that same silent-failure infrastructure. If a receiving endpoint is down, nobody — not the clinic, not Dentolize support — is notified. See For Support and For Quality for detail.