For Stakeholders

Why this matters

This PR turns Dentolize from a closed product into a platform. Every prior integration (WhatsApp, ZATCA e-invoicing) was a bespoke, Xolize-engineered connection. This ships the generalized machinery — auth, consent, scoping, webhooks, an SDK, admin tooling — so that the next integration doesn't require a new engineering project each time. That's a structural leverage change, not just a feature: it changes Dentolize's integration cost curve from linear (one build per partner) toward roughly flat (partners build against a stable, documented API).

Scope of this change, honestly stated

This is a large PR — 320 files, ~42,500 lines added, 6 new database models, a new npm package, two new UIs (one clinic-facing, one internal-admin). It is also, as shipped, a platform with one working example on it, not a marketplace. The only live listing is the internal demo plugin used for onboarding and sandbox testing. Realizing the business value of this PR requires a second motion this code doesn't cover: recruiting and onboarding real partners, and — eventually — a self-serve developer portal, which doesn't exist yet (listings are hand-entered by Xolize staff today).

Risk surface

• New attack surface. This is a new, authenticated, internet-facing API with its own auth (dtz_ tokens), its own rate limiting, and its own request pipeline, separate from the GraphQL API the rest of the product uses. It reuses the platform's tenancy-isolation pattern (the same getWhereFor* helpers used everywhere else) rather than inventing new isolation logic, which is the right call from a risk standpoint — but it's still new code, at scale (30 REST controllers), that deserves security review proportional to its size. See For Quality.
• Legal/compliance exposure is explicit and by design, not incidental. Installing a plugin makes an external company a data processor for a clinic's patient data. The DPA acceptance flow and scope-tier consent screen exist specifically to keep that exposure clinic-consented and auditable, not to eliminate it — Dentolize still cannot technically verify that a partner actually deletes data after uninstall or a patient.deleted event; that remains a contractual, not technical, guarantee (docs/plugin-platform/compliance.md).
• A few known, documented gaps ship as-is, not silently. The platform's own internal docs list specific unfinished items: some money-path webhook emit gaps (e.g. editInvoiceWithPayments paid-transitions not yet firing invoice.paid), no field-level encryption at rest (a pre-existing platform posture), and PATCH /claims/:id deferred to another branch. None of these are hidden — they're written down in docs/plugin-platform/compliance.md and api-expansion-roadmap.md as the team's own acknowledged backlog.
• Consent UI is coarser than the data model supports. The schema already has per-optional-scope consent and branch-scoped tokens (Plugin.optionalScopes, PluginToken.branchIds), but neither UI exposes them yet — see How plugins work. This isn't a defect so much as unfinished surface area; worth tracking as a near-term follow-up rather than assuming it's "done."

What to ask before calling this "launched"

1. Is there a real second plugin listing, beyond the demo, that a real partner can install? (Answers the "is this a platform or a proof of concept" question concretely.)
2. Who owns the ongoing review workload of vetting and publishing new listings through the current manual admin tool, and does that scale past a handful of partners?
3. Has the new REST API surface had a security review distinct from the existing GraphQL API's review history? (Different auth model, different middleware stack, same underlying data.)
4. Is there a support runbook for "a plugin is behaving badly" — suspend-from-admin exists technically, but who's on call to notice and act?