Webhooks send configured event data from Nviti to an external HTTP receiver, such as an n8n or ActivePieces workflow.
Create a webhook
Open Monitoring → Webhooks and select Create.
| Field | Purpose |
|---|---|
| Name | A label your team recognizes. |
| Webhook URL | Production receiver URL. Use a trusted HTTPS endpoint. |
| Test Webhook URL | Optional separate test receiver; when absent, the test action appends /test to the production URL. |
| Bearer Token | Optional authentication token sent to the receiver. |
| Active | Availability for integrations that select active webhooks. |
Save the record, then attach it to the relevant form or supported workflow action. Creating a webhook record alone does not subscribe it to every workspace event.
Send a test
Open the test controls, review the JSON payload, and select Send Test Webhook, or use the row's Test action. Confirm the receiver and payload first: a test is a real HTTP request to the test URL.
The result includes success state, HTTP status, and response body. A missing test URL is not the same as testing the production URL, because Nviti adds /test when no explicit test URL is configured.
Request and response behavior
The shared webhook service sends a JSON POST request with the configured Bearer authentication and a 30-second timeout. Production payloads depend on the triggering source; inspect a representative test and run before building the receiver's field mapping.
Do not depend on universal X-Nviti-Event or X-Nviti-Delivery headers: the shared service does not add them. Use identifiers actually present in the source payload when implementing duplicate handling.
A successful 2xx response confirms the receiver accepted the request, not that its downstream workflow completed. The shared service records failed requests but does not itself provide a universal automatic retry guarantee.
Review runs
Open Runs for request payload, HTTP status, response, timing, success/failure, and test/production context. The list also shows run counters. Treat these counters as recorded runs, not a guarantee of successful downstream actions.
Tokens are encrypted in storage and masked in the interface. Leaving the token field blank on edit preserves the existing value. Payloads and responses can still contain business data, so restrict access to run details.
Troubleshooting
Check that the receiver accepts JSON POST requests, the authentication matches, and the URL is reachable within the timeout. If no production request appears, confirm the workflow actually selects the webhook and reaches its triggering action.
See Workflows and API Actions.