For Support

Where clinics will find this

Sidebar → Settings → Plugins (only visible to users with the viewPlugins permission, and only if the FEATURE_PLUGIN_HUB flag is on for that clinic — if a clinic reports "I don't see Plugins in Settings at all," check both of those before assuming a bug). Full URL: /plugins. A specific installed plugin's configuration is at /settings/plugins/<slug>, which additionally requires managePlugins.

Common questions and where to look

"I can't find the API token / it's not showing." Tokens are shown in full exactly once — immediately after install, or immediately after a manual Rotate. After that, the Connection tab only ever shows a masked prefix (dtz_test_0i6RBb…) plus a mode tag. This is intentional, not a bug — there is no "reveal" action anywhere. If a clinic lost the token, their only recourse is Rotate, which invalidates the old one and shows a new one once.

"The webhook secret is different from the API token — which do I give the developer?" Both, and they're separate things. The API token (dtz_test_…/dtz_live_…) is what the plugin uses to call Dentolize. The webhook signing secret (whsec_…) is what the plugin uses to verify that a notification claiming to be from Dentolize is genuine. Each webhook endpoint has its own signing secret, independent of the API token and independent of other endpoints.

"A plugin's webhook isn't receiving anything." Walk them through the Activity tab first — it shows every delivery attempt with status, attempt count, and HTTP response code. A FAILED or EXHAUSTED status with a real response code (or none at all) usually means the developer's endpoint is down or misconfigured, not a Dentolize-side issue. Have them use Send test event on the Connection tab to generate a fresh attempt without waiting for a real trigger. After 20 consecutive failed deliveries, Dentolize auto-disables the endpoint and should notify the clinic — if an endpoint shows Active: off with a Disabled: <reason> note, that's why, and the fix is on the developer's side, then a manual re-enable via the Active toggle.

"I installed the wrong plugin / want to remove one." Danger tab → Uninstall. They'll need to type the plugin's slug to confirm. This is immediate and irreversible from the clinic side — API access and webhook delivery stop right away. There's an optional "request data deletion" checkbox; be clear that this is a request sent to the developer, not a guarantee Dentolize can verify or enforce.

"Why does installing this plugin warn me about patient data?" That warning only appears when a plugin requests the patient_pii sensitivity tier — it's the platform being deliberately loud about the most sensitive category. Reassure them it's the same warning for every plugin at that tier, not something specific to this one plugin looking suspicious.

"Can I control exactly what a plugin can and can't do, beyond the initial approval?" Not per-scope, as shipped — a clinic accepts or doesn't accept the full requested scope list at install. There's no "turn off patient data access but keep appointment access" toggle after the fact; the only lever after install is uninstall entirely, or rotating/revoking credentials.

"Does uninstalling delete my settings for that plugin?" No — per the in-app copy on the Uninstall confirmation itself: settings and activity history are kept for the clinic's records even after uninstall. Only API/webhook access is cut immediately.

Escalate to engineering when

• A clinic reports data appearing in a plugin's responses that shouldn't be visible for its granted scopes — this is a security-relevant report, escalate immediately rather than troubleshooting further yourself.
• The internal Xolize plugin-registry admin tool (/ZROYKuKEVCvQykPlS4kP/plugins, distinct login from clinic support tooling) isn't loading — this is not something clinic-facing support can fix, route to engineering.