Allow native Webhooks to authenticate via Connections (Basic Auth) instead of plaintext custom headers
Summary
Please allow native Webhooks (Workflow Rules > Instant Actions > Webhooks) to authenticate against the destination endpoint using the existing Connections feature, with support for Basic Authentication. Today the only way to authenticate a webhook is to hardcode a secret (token, API key, signature) into a custom header or custom parameter, where it is stored and displayed in cleartext.
Current Behavior
When configuring a webhook, the standard pattern to secure the receiving endpoint is to add a custom header such as:
Authorization: Bearer <secret>
X-Webhook-Token: <secret>
This works, but the secret value is stored and shown in plaintext everywhere the webhook configuration can be read.
Problem : The secret is exposed in several places :
Because the value lives in the webhook config as clear text, it leaks through every surface that can read that config:
1. Sandbox / external developers: When a sandbox is shared with external developers (agencies, integrators, contractors), they can open the webhook configuration and read the authorization secret directly. A credential that is supposed to be private to the production integration is now visible to third parties.
2. Zoho CRM MCP server: Reading webhook configuration through the Zoho MCP server returns the custom header values verbatim. Any connected assistant or agent (or anyone with access to that MCP) can retrieve the secret. There is no way to mark the header as sensitive or to redact it.
3. General config read access: Anyone with permission to view the workflow rule can see the secret. There is no separation between "can edit the webhook" and "can read the credential."
In short: a value that is functionally a password is treated as plain configuration data, which makes it impossible to keep webhook authentication truly confidential.
Proposed solution :
Let webhooks reference a Connection (Setup > Developer Space > Connections) for authentication, the same way custom functions already do with invokeurl ... connection:"...".
Specifically:
- Add an Authentication option to the webhook configuration that lets the user pick an existing Connection.
- Support Basic Authentication connections (username / password) as a connection type usable by webhooks.
- Inject the credential at runtime, server side, so the secret is never displayed in the webhook UI, never returned by the API or MCP, and never visible in a sandbox.
The credential would then be managed centrally as a Connection (rotatable, access controlled) instead of being duplicated in plaintext across webhook headers.
Benefits
- No secret exposure in sandbox, API, or MCP responses.
- Centralized credential management: rotate the password in one Connection instead of editing every webhook.
- Least privilege: editing a webhook no longer means reading its credential.
- Consistency: webhooks would reuse the same secure auth mechanism that Deluge custom functions already rely on.