WebHookDeck: Watch Webhooks Privacy Policy

# WebHookDeck Privacy Policy Last updated: September 4, 2026 WebHookDeck is published by Quazmoz / Quinn Favo. It is a local-first Android and Wear OS utility for deliberately triggering user-configured HTTP or HTTPS requests. ## Summary WebHookDeck does not require a developer account and does not use a Quazmoz webhook relay. The app does not include advertising, a developer analytics SDK, or a developer crash-reporting upload SDK. Action configuration is kept on your devices. Sensitive values are encrypted at rest. A request is sent only when you explicitly test or trigger an action. ## Data stored locally Depending on the features and execution mode you choose, WebHookDeck can store locally: - Action names and descriptions. - Endpoint configuration. - HTTP method, headers, query configuration, and request body. - Folder and ordering metadata. - Execution target, timeout, confirmation, and other action settings. - Sanitized recent execution history and result classification. - Optional local Pro entitlement state. - Phone/watch synchronization metadata needed to keep the selected execution model consistent. Full action URLs, request bodies, and values marked as Secret are stored with Android Keystore-backed encryption. Older plaintext sensitive values are re-encrypted when migrated by supported app versions. Android application backup and device transfer are disabled for WebHookDeck local application data so encrypted configuration is not intentionally moved through normal Android backup. ## Phone and watch synchronization WebHookDeck uses the Wear OS Data Layer provided through Google Play services for paired-device communication. WebHookDeck supports two execution models: ### Run on watch For actions configured to run on the watch, the watch receives the configuration required to execute that action. Sensitive values are stored using encrypted local storage on the watch before use. ### Run via phone For actions configured to run via the paired phone, executable request configuration remains phone-authoritative. The watch receives only bounded display and routing metadata needed to identify and request the action. The Run via phone watch snapshot is designed to exclude full endpoint path/query data, request headers, query values, request body, HMAC material, and action description. A reduced origin may be retained where required for safe display or classification. A watch-to-phone execution command carries only control metadata such as protocol/schema information, request identifier, action identifier, revision, and confirmation state. It does not carry the action URL, credentials, query values, request body, or HMAC secret. Google Play services may process device and transport information under Google's own terms as part of providing the Wear OS Data Layer. ## Network requests WebHookDeck sends network requests only after an explicit user test or trigger. - Run on watch sends the request from the Wear OS device. - Run via phone sends the request from the paired Android phone. For HTTPS destinations, WebHookDeck relies on normal TLS certificate and hostname validation. Plain HTTP is supported only for explicitly configured local or homelab targets. The app requires disclosure/confirmation and validates the effective destination so public cleartext HTTP targets are rejected. Local validation covers loopback/private IPv4, link-local ranges, and supported IPv6 local ranges; DNS names must resolve to an allowed local address. The request layer pins the approved effective address where needed to reduce DNS-rebinding risk. Redirects are revalidated. WebHookDeck does not permit an HTTPS-to-HTTP downgrade, strips credential-bearing headers when the origin changes, and removes target-bound HMAC material when a redirect changes the target. If a Run via phone result is ambiguous, WebHookDeck does not automatically resend the request because the first attempt may already have reached the destination. ## Home Assistant guided setup If you use the Home Assistant guided setup flow, a token you type is kept only in temporary setup state until you save the action. After saving, the token is stored as an encrypted Authorization Secret rather than ordinary plaintext action metadata. Run via phone is the default execution target for Home Assistant actions so the full executable configuration can remain phone-authoritative unless you deliberately choose otherwise. Home Assistant is an external destination selected and controlled by you. WebHookDeck does not relay Home Assistant requests through a Quazmoz server. ## Help, feedback, and sanitized diagnostics WebHookDeck provides user-initiated Help & feedback actions on phone and supported Wear OS surfaces. The canonical support page is https://consultant.quinnfavo.com/support/webhookdeck. WebHookDeck does not automatically upload support diagnostics. Diagnostic text is generated locally from a strict allowlist and is copied only after you explicitly choose to copy it. You decide whether to paste or submit it. Safe diagnostic fields can include app/version information, device/API information, support source/context, HTTP method, selected execution target, HTTP status where available, bounded result/network/TLS/timeout classifications, connectivity/remote-support state, and retry-safety classification. Diagnostics intentionally exclude: - Endpoint URL, hostname, path, or query data. - Request headers, Authorization values, API keys, tokens, Home Assistant credentials, HMAC material, or other secrets. - Request or response bodies. - Private-infrastructure details that would reveal sensitive destination information. - Raw Wear Data Layer payloads. - Google Play purchase tokens or payment information. - Arbitrary logs, logcat output, or raw exception text. - User-entered action names when they could contain private content. The external support URL is limited to bounded support type, source, safe context, and version metadata. It does not automatically attach diagnostics or request configuration. On Wear OS, support navigation can use the paired phone through AndroidX Wear remote interaction without attaching the diagnostic bundle. Information you later type or paste into the support website is a separate, explicit web interaction. ## Google Play Billing WebHookDeck may offer an optional one-time lifetime Pro purchase through Google Play Billing. Google Play processes payment credentials, transaction history, and account association. WebHookDeck receives the product and ownership state needed to present, acknowledge, restore, and locally cache the entitlement. WebHookDeck does not receive payment-card credentials. ## Import and export WebHookDeck provides user-controlled import/export features. A normal credential-free export is designed to remove Secret values and blank sensitive URL/body material rather than quietly placing credentials into an ordinary file. If you deliberately choose an export mode that includes secrets, the exported file can contain sensitive information in plaintext. The app treats that as an explicit high-risk action and the resulting file is under your control once written to the selected storage location. Imported files should be reviewed before execution because they can define network destinations and request configuration. ## Permissions and cleartext configuration WebHookDeck uses INTERNET for user-triggered requests and Google Play/Wear platform functionality, BILLING for optional Pro, and VIBRATE where haptic feedback is enabled. The application can permit cleartext traffic at the Android manifest level because user-configured local/homelab HTTP targets are a supported feature. That manifest capability is not blanket permission to contact arbitrary public HTTP targets: the request layer applies the local-only restrictions described above. WebHookDeck does not require location, microphone, camera, contacts, calendar, broad file access, health/body-sensor, or advertising-ID permission for its core webhook-launching workflow. ## Accounts, advertising, analytics, and developer backend The current app has: - No WebHookDeck user account system. - No Quazmoz webhook relay or content backend. - No advertising SDK. - No developer analytics SDK. - No developer crash-reporting upload SDK. Requests go to destinations you configure, not to a Quazmoz service, except when you explicitly open the separate Quazmoz Help & feedback website. ## Deletion You can remove WebHookDeck local data by deleting actions, clearing app storage, or uninstalling the app from the relevant phone/watch device. Data already sent to an external endpoint is controlled by that endpoint and must be managed there. ## Security WebHookDeck minimizes exposure by encrypting sensitive configuration, keeping Run via phone executable state phone-authoritative, restricting cleartext HTTP to validated local destinations, revalidating redirects, preventing silent duplicate retry after ambiguous results, excluding sensitive values from diagnostics, and disabling Android application backup for app-local data. No software can guarantee absolute security. You are responsible for the endpoints, credentials, automations, and infrastructure you configure. ## Children's privacy WebHookDeck is a general-purpose developer/automation utility. It does not include advertising, social features, or a developer-operated account service. ## Changes This policy will be updated when WebHookDeck materially changes its permissions, SDKs, synchronization model, network protections, billing, support-data behavior, storage, or other data handling. ## Contact For privacy questions or support, use WebHookDeck Help & feedback or contact Quazmoz@vivaldi.net.