Skip to main content
POST
/
v2
/
workspace
/
notificationconfig
/
update
Update Notification Config
curl --request POST \
  --url https://api.velt.dev/v2/workspace/notificationconfig/update \
  --header 'Content-Type: application/json' \
  --header 'x-velt-api-key: <x-velt-api-key>' \
  --header 'x-velt-auth-token: <x-velt-auth-token>' \
  --data '
{
  "data": {
    "useNotificationService": true,
    "notificationServiceConfig": {
      "triggers": {},
      "delayConfig": {
        "isEnabled": true,
        "delaySeconds": 123
      },
      "batchConfig": {
        "document": {
          "isEnabled": true,
          "batchWindowSeconds": 123,
          "maxActivities": 123
        },
        "user": {
          "isEnabled": true,
          "batchWindowSeconds": 123,
          "maxActivities": 123
        }
      }
    }
  }
}
'
{
  "result": {
    "status": "success",
    "message": "Notification configuration updated successfully.",
    "data": {
      "useNotificationService": true,
      "notificationServiceConfig": {
        "delayConfig": {
          "isEnabled": true,
          "delaySeconds": 30
        }
      }
    }
  }
}
Use this API to update the in-app notification service configuration for a workspace. At least one of useNotificationService or notificationServiceConfig must be provided. The config is deep-merged with the existing value, so omitted sub-fields are preserved.
This endpoint uses API-key-level auth: pass x-velt-api-key and x-velt-auth-token as headers. You can obtain these from the Get Auth Tokens endpoint.
The numeric delay/batching fields must be integers within these ranges, otherwise the request is rejected with INVALID_ARGUMENT:
  • delayConfig.delaySeconds: 10–15552000 (10 seconds to 6 months)
  • batchConfig.document.batchWindowSeconds / batchConfig.user.batchWindowSeconds: 10–604800 (10 seconds to 1 week)
  • batchConfig.document.maxActivities / batchConfig.user.maxActivities: 2–50
Defaults on first enable. If you enable the service (useNotificationService: true) and the stored config has no triggers yet (defaults are seeded even if delayConfig / batchConfig already exist), a default set of triggers is seeded automatically: the standard comment triggers and all huddle triggers are turned on. Delay and batching stay off — no delayConfig or batchConfig is written by the seeding. Existing non-trigger fields are preserved, and any notificationServiceConfig values you send in the same request are merged on top of these defaults.
The response data echoes the latest post-write state as { useNotificationService, notificationServiceConfig } — the same shape returned by Get Notification Config. Fields not part of your request fall back to the existing stored values.

​
Endpoint

POST https://api.velt.dev/v2/workspace/notificationconfig/update

​
Headers

​
x-velt-api-key
string
required
Your API key.
​
x-velt-auth-token
string
required
Your Auth Token.

​
Body

​
Params

​
data
object
required

​
Example Request

{
  "data": {
    "useNotificationService": true,
    "notificationServiceConfig": {
      "delayConfig": {
        "isEnabled": true,
        "delaySeconds": 30
      }
    }
  }
}

​
Example Response

​
Success Response

{
  "result": {
    "status": "success",
    "message": "Notification configuration updated successfully.",
    "data": {
      "useNotificationService": true,
      "notificationServiceConfig": {
        "delayConfig": {
          "isEnabled": true,
          "delaySeconds": 30
        }
      }
    }
  }
}

​
Failure Response

{
  "error": {
    "status": "INVALID_ARGUMENT",
    "message": "At least one of useNotificationService or notificationServiceConfig must be provided"
  }
}

{
  "result": {
    "status": "success",
    "message": "Notification configuration updated successfully.",
    "data": {
      "useNotificationService": true,
      "notificationServiceConfig": {
        "delayConfig": {
          "isEnabled": true,
          "delaySeconds": 30
        }
      }
    }
  }
}