Use webhooks to connect support events to other systems

Updated Wednesday, October 28, 2026 · Marc Staine

A webhook is an automatic message from one system to another when an event occurs. Supportbench sends data to a receiving address, called an endpoint; the receiving system decides what to do with that data. For a B2B support team, this can connect a new case or customer change to another approved operational process without asking an agent to re-enter the same reference. A useful webhook needs a clear purpose, a supported receiving system and an owner who verifies the result.

At a glance

For: support operations leads planning integrations with an administrator or receiving-system owner. Applies to: Supportbench Core.

Start here: Settings → API → Webhooks, or Settings → Configuration → Workflows, depending on the required behavior

Understand the four parts of the connection · Choose the correct Supportbench mechanism · Know what event subscriptions currently offer · Example: connect case creation to an account-review process · Prepare the decision with your technical owner · Prove the whole outcome · Change or retire a connection with its owners · Recognize the common failure boundary

Understand the four parts of the connection

Term	What it means for a support team
Event	The change that matters, such as a case being created. Choose the event that actually represents your business need.
Endpoint	The receiving system’s complete web address for these requests. Your technical owner supplies it; it is not usually the system’s normal home page.
Payload	The structured data sent in the request, normally JSON. JSON is a machine-readable way to label values; agents do not need to write application code to decide which business event they need.
Processing	What the receiver does after receiving the request. It might record a reference or start an approved process, but that behavior must be implemented and tested by the receiver owner.

A webhook avoids constant polling for the same change, but it is not a promise of instant or guaranteed delivery. A saved configuration, an HTTP response and a completed downstream business action are three different pieces of evidence.

Choose the correct Supportbench mechanism

Need	Use	Important boundary
Send one supported event to an approved endpoint	Event subscription in Settings → API → Webhooks	The editor has Event and Endpoint; it has no authentication fields or custom body editor.
Send a case event only when specific workflow conditions match	Webhook action in Settings → Configuration → Workflows	The rule’s trigger, requirements, conditionals, exclusions and other controls determine whether it runs.
Use username/password, bearer token or a custom header with a conditional case notification	Supported authentication in the Workflow Webhook action	Confirm the receiver accepts the actual workflow payload and selected authentication method.
Use a provider-specific integration, such as linking a Jira issue to a case	The relevant integration guide	A generic webhook is not automatically a replacement for the integration’s mapping, permission and relationship features.

Do not configure both mechanisms for the same purpose without considering duplicates. Their payloads and processing paths differ. Copying a working endpoint from one to the other does not establish that the receiver understands the new request.

Know what event subscriptions currently offer

The current subscription editor offers Case Created, Case Updated, Case Status Changed, Case Closed, Case Reopened, New Activity, Company Created and Company Updated. Choose a specific event when it meets the requirement; a general update event can create unnecessary volume.

Contact events are not selectable in this editor. An older stored event may remain visible for compatibility, but that is not proof that you can create the same subscription now. The old “three webhook types” description is not the current event catalog.

Example: connect case creation to an account-review process

A customer-success team wants to know that an important account has opened a new request. First define the actual result: should the other system store a case reference, create a review task or notify a designated owner? Then identify who implements that receiver behavior. Supportbench sends the event; it does not infer the target system’s task fields or message format.

If the receiver needs every new case and can accept the subscription contract, a Case Created subscription may fit. If only a defined customer or case condition should qualify, use a suitable Case workflow and its Webhook action. Test both a matching case and a nonmatching case, then confirm that the resulting task belongs to the right customer and owner.

B2B benefit to aim for

The benefit is continuity between teams: a downstream record points back to the same customer issue and the support owner remains clear. Sending more events is not a success measure by itself. Measure whether the intended follow-up appears reliably, is assigned correctly and avoids duplicate work.

Prepare the decision with your technical owner

Describe the business event and intended result in one sentence. Include who must act and how they will know the action is complete.
Choose the Supportbench mechanism, required scope and expected event volume. Identify whether customer or internal data will leave Supportbench.
Ask the receiving-system owner for the approved HTTPS endpoint, accepted payload and supported authentication. Do not guess a URL or assume an incoming Slack/CRM webhook accepts Supportbench JSON directly.
Agree how the receiver handles repeated deliveries, temporary outages and missing results. Establish a reconciliation procedure before relying on automation.
Prepare approved sample records and a test destination or controlled production test. Keep customer data and secrets out of public webhook inspection services.
Assign the configuration owner, receiver owner and operational contact for failures or endpoint changes.

Prove the whole outcome

Save and reopen the intended subscription or workflow, confirming event, endpoint, scope and any authentication settings.
Generate the agreed test event through the normal authorized workflow. Use a unique harmless reference so you can trace it.
Check receiver arrival, payload interpretation and the actual downstream business result. Confirm customer association and ownership.
Test a nonmatching event or condition where applicable. Verify that an unrelated customer does not trigger the intended restricted process.
Have the receiver owner demonstrate repeat handling and recovery from temporary failure. Do not assume retries provide exactly-once processing.
Record the outcome and monitoring owner. Repeat relevant checks after payload expectations, credentials, endpoint addresses or workflow conditions change.

Change or retire a connection with its owners

For event subscriptions, updates affect future events. Deleting a subscription also removes pending deliveries for the account and endpoint, including deliveries shared by another subscription at that endpoint. Review shared use and recovery before deletion; removing one row is not necessarily limited to that event’s queued work.

A Workflow action has its own configuration and delivery path. Review the rule’s other actions before disabling or editing it. A rule used for routing or notifications should not be disabled casually just to stop one external request. Use the applicable setup guide below to make a deliberate change.

Recognize the common failure boundary

Symptom	Where to investigate
Nothing arrives	Correct event, matching conditions, saved endpoint, asynchronous delivery and receiver availability.
The receiver returns an authentication error	Mechanism capability and receiver requirements. Event subscriptions do not have the Workflow action’s credential controls.
A request arrives but no task is created	Receiver payload parsing and business processing. Arrival alone is not the intended outcome.
Two tasks are created	Overlapping subscriptions/workflows or missing receiver duplicate handling.
The wrong customer is associated	The receiver’s identity mapping and the actual supplied source data. Do not infer customer identity from a display name alone.
An old tutorial shows different controls	Follow the current guide for the selected mechanism; subscription and workflow screens are separate.

Was this article helpful?