Configure event webhook subscriptions

Updated Monday, October 26, 2026 · Marc Staine

Webhooks deliver supported event information to an external endpoint so another system can respond to Supportbench changes. Keep subscriptions specific and verify the receiving system’s processing before relying on the automation.

Applies to: Supportbench Core. Location: Settings → API → Webhooks. Access and available controls depend on your role and account capabilities.

Before you begin

You need permission to edit this configuration. Ask an administrator if the page is available but its editing controls are not.
Review the current configuration and where it is used before making a change. Available choices depend on your account, enabled modules, division access and role.
Use a test record or a controlled test account for behavior checks. Do not change production routing or send customer messages just to try an example.

Configure and verify

Open Settings → API → Webhooks.
Review existing subscriptions to avoid duplicate deliveries.
Choose the supported event and enter the intended endpoint.
Save, then trigger a controlled test event and inspect the receiver’s result.
Confirm the receiver handles repeated or unexpected events safely before using it operationally.

Settings reference

Subscription

Setting	What it controls	How to choose
Event	Supported events include case creation, update, closure, reopening and status changes, new activity, and company creation/update.	Select the event actually required by the receiver; use the options offered by your account.
Endpoint	Absolute HTTP or HTTPS URL, up to 255 characters.	Use HTTPS and the receiver’s documented endpoint.
Existing unsupported event	A stored event may remain visible even when it is no longer offered for new setup.	Review the existing integration before replacing or removing it.

Behavior to know

Deleting an endpoint can remove pending deliveries and affect subscriptions sharing that endpoint. Review shared use before deletion.
A saved subscription is not proof that the destination received or processed an event.

Recommended use

Use terminology that agents and customers already understand. Explain the intended meaning in the description.
Keep the initial configuration small enough for people to choose consistently. Add options when they represent a real operational difference.
Review existing references before renaming, changing scope, or deleting. Where supported, deactivate an obsolete option before considering permanent deletion.

Worked example

Configure a case-created subscription for a controlled receiving endpoint.
Create one test case and confirm the receiver recognizes its identifier.
Check receiver failures and repeated events before extending the integration.

Troubleshooting

Problem	What to check
The item is missing from a picker.	Check Active, division access, parent hierarchy, enabled modules, and the user’s role. Reopen the consuming form after saving.
The form rejects a save.	Read the displayed validation message. Check required values, text limits and permitted scope; do not change unrelated settings to bypass validation.
An existing record still shows an old value.	A configuration change and a record change are different operations. Inspect the record and relevant references before assuming the save failed.

Configuration → Configure workflows and automation
API → Create and manage API tokens

Was this article helpful?