Skip to main content
Set up a webhook endpoint to receive real-time notifications for the following Velt events:

Setting up a Webhook

To enable Webhooks go to the Configurations -> Webhook Service in the Velt Console, or click here

Webhook Auth Token

  • Optional security feature to authenticate webhook requests.
  • Set a unique auth token in your Velt console’s webhook settings.
  • We add this token to the Authorization header of each request as Basic YOUR_AUTH_TOKEN.
  • Helps you verify that requests are from Velt, not from unauthorized sources.

Endpoint URL

  • This is the endpoint that we will send the webhook data to. This is usually hosted on your server.

Payload Encoding

  • Enable Base64 encoding for webhook payloads (disabled by default).
  • Addresses issues with payloads containing HTML tags that may fail due to strict endpoint policies.
  • If enabled, ensure your server can decode Base64 encoded payloads.
  • Example of decoding a Base64 encoded payload:

Payload Encryption

  • Enable payload encryption for enhanced security (disabled by default).
  • Configure this option in the Velt Console.
  • Encryption details:
    • Payload encryption: AES-256-CBC
    • Key encryption: RSA with PKCS1 OAEP padding and SHA-256 hash
  • Public key format:
    • Provide only the base64-encoded key string, without PEM headers/footers
    • Recommended key size: 2048 bits
  • Example of setting up decryption for Node.js:

Payload Schema

  1. Default payload: WebhookV1Payload, the common fields shared across all events
  2. Encoded payload: If you have enabled payload encoding, you will receive the payload in this format: WebhookV1PayloadEncoded
  3. Encrypted payload: If you have enabled payload encryption, you will receive the payload in this format: WebhookV1PayloadEncrypted
If you have configured notification settings, per-user notification preferences (usersOrganizationNotificationsConfig or usersDocumentNotificationsConfig) will be included in the webhook payload.

Comments Events

The Comments component will emit webhook notifications whenever an action type occurs on a comment. Payload Schema: WebhookV1Payload + Comment Events

List of Action Types

Sample Webhook Data

Comment Visibility

Comment notification webhooks respect the comment’s visibility. When a comment is private, users who cannot see it are listed in accessDeniedUsers. Drop those users from your own fan-out. accessDeniedUsers covers two independent sources:
  • Users denied by your Permission Provider.
  • Users denied by the comment’s visibility.
In both cases the entries are client user IDs. The comment author and any user or organization named in the comment’s visibility normally receive the notification. This applies to every comment action type, including deleted. Notifications for private comments also carry a visibility object that mirrors the comment’s visibility settings.
Payload excerpt
Public comments carry no visibility key, and neither do notifications created before this release. Existing consumers keep working unchanged. No integration change required. Treat visibility and accessDeniedUsers as informational. Velt re-verifies comment visibility on the server before it sends the webhook. Do not use these fields to widen who you forward a notification to. For advanced (V2) webhooks, see Comment Visibility.

Huddle Events

The Huddle component will emit webhook notifications when a user creates or joins a group huddle. Payload Schema: WebhookV1Payload + Huddle Events

List of Action Types

CRDT Events

The CRDT component will emit webhook notifications when data changes occur. Webhooks are enabled by default with a 5-second debounce. Payload Schema: WebhookV1Payload + CRDT Events
Learn how to configure CRDT webhooks in the CRDT Core Setup documentation.

Action Type

Sample Webhook Data