Skip to content
Help Center
Submit a request Sign in

Tags

Configure event webhook subscriptions

Updated Wednesday, October 28, 2026 · Marc Staine

Event webhook subscriptions send supported Supportbench changes to a receiving system through asynchronous JSON POST requests. Use them when another approved system needs to respond to a specific case, activity or Company event. A support operations owner chooses the business event; the receiving-system owner provides and validates the endpoint and its processing. Saving a subscription establishes configuration, not proof of delivery or successful downstream work.

Applies to: Supportbench Core. Location: Settings → API → Webhooks. Viewing and administering this page requires Administer API configurations (api_access); editing or deleting also requires the section’s edit access.

Before you begin

  • Choose the business outcome and the event that represents it. For example, a Case Created subscription can notify an approved account-operations receiver that a new support request exists. The receiver must implement any downstream record creation; Supportbench does not automatically turn arbitrary JSON into a Slack message or CRM task.
  • Have the receiving-system owner supply the exact HTTPS endpoint and confirm it accepts the Supportbench JSON payload. This editor has no authentication fields, custom request-body editor or test-send button. Do not assume it signs requests or adds a token configured elsewhere.
  • Review the data the event can disclose and approve the destination for that customer information. Use an appropriate receiver or gateway whose access design supports this mechanism. If the receiver requires credentials that this subscription cannot send, evaluate a suitable workflow action or supported integration instead.
  • Identify an operations owner and a technical owner for delivery failures, duplicate events and endpoint changes. A receiver should handle repeated events without creating duplicate business records.
  • Prepare approved test records and receiver access. Record existing subscriptions using the same endpoint before changing or deleting any of them.

Configure and verify

  1. Open Settings → API → Webhooks. Use Search event or endpoint and Filter by event to inspect existing subscriptions. Clear the search/filter if the intended row appears missing.
  2. Open New webhook. Choose one supported Event: Case Created, Case Updated, Case Status Changed, Case Closed, Case Reopened, New Activity, Company Created or Company Updated. Contact events are not selectable in this current editor.
  3. Enter the complete Endpoint URL, including its scheme and host. Use HTTPS for customer data. The field accepts absolute HTTP or HTTPS URLs up to 255 characters; surrounding spaces are trimmed. A supported URL format is not evidence that the receiver accepts the request.
  4. Select Save webhook. Resolve any validation or duplicate-subscription message, then reopen the saved row and verify both event and endpoint. An identical account/event/URL subscription is rejected.
  5. Create the agreed controlled event through normal authorized product use. For Case Created, create the approved test case; changing an existing case is a different event. There is no test-send button in this subscription editor.
  6. Have the receiver owner confirm receipt of an application/json POST, inspect a representative payload and verify the intended downstream outcome. Record the source item and timing so delayed or repeated deliveries can be investigated.
  7. Repeat an appropriate negative check, such as a different event that should not trigger this subscription. Test receiver behavior for repeats and temporary failure before treating the automation as operationally verified.

Settings reference

Subscription and list controls

SettingWhat it controlsHow to choose
EventOne of eight supported case/activity/Company events.Choose the narrow event the receiver actually needs. New Activity is a different signal from Case Created.
EndpointAbsolute HTTP or HTTPS address, up to 255 characters; surrounding spaces are trimmed.Use the receiver’s approved HTTPS URL. Avoid secrets in URLs or copied diagnostics, and do not send customer events to a public debugging site.
Search event or endpoint / Filter by eventNarrows the visible subscription list.Use both to inspect shared endpoint use. Clear them before concluding a subscription is missing.
Save webhook / Update webhookSaves a new subscription or changes an existing one. Updates affect future events.Reopen and verify the saved row. Do not expect editing a URL to rewrite already queued deliveries.
Delete webhookRemoves the subscription and every pending delivery for the account and endpoint, including deliveries shared by other subscriptions at that endpoint.Coordinate removal with all owners using the endpoint. Deleting a row is not a harmless way to clear a filter or pause one event.
Existing unsupported eventAn old stored event can be displayed even though it is not offered for new setup.Review that integration before replacing it. Historical compatibility is not a reason to promise the event can be created in the current editor.

Behavior to know

  • Subscription delivery is queued and asynchronous. Do not promise instant delivery, a fixed latency or exactly-once processing. Retries can occur, and the receiver must handle repeats safely.
  • The request contains serialized event data. It is not the same envelope as the conditional Workflow Webhook action. Inspect a representative subscription request instead of copying a guessed schema from another webhook guide.
  • This settings screen configures only the event and endpoint; it has no request-authentication control or payload-field selector. A successful HTTP response alone does not prove the receiver completed its business action.
  • HTTP 410 Gone is treated as endpoint removal by delivery processing. A receiver should not use 410 for a temporary outage. Coordinate receiver status behavior with its owner.
  • Deletion removes pending deliveries for the shared account/endpoint. Updating changes future configuration but does not retroactively retarget already queued events. Preserve an operational recovery plan before changing destinations.

Recommended use

  • Keep the first subscription narrow and prove one complete business outcome. Add other events only when the receiver has a defined use for them; Case Updated can produce more volume than a specific status event.
  • Keep an integration register containing event, destination owner, approved data use, expected outcome and recovery contact. Do not put credentials or raw customer payloads in that register.
  • Ask the receiver owner how duplicate detection, temporary failures and reconciliation are handled. The support team needs a way to find a missing downstream task without creating duplicates by hand.
  • Coordinate endpoint changes as an integration change. Review all rows using the old URL, queued-work implications and receiver readiness before updating or deleting.
  • Use a Workflow Webhook action when conditional case logic or its supported authentication controls are required. Keep the two mechanisms and their payload contracts separate.

Worked example: notify an account-operations service of new cases

  1. Agree that a receiver will record a support-request reference for account operations. The technical owner provides an approved HTTPS endpoint and implements handling of the actual Case Created subscription payload.
  2. Create one Case Created subscription for that endpoint. Save and verify the event and address.
  3. Create an approved sample case for a test customer. Check the received payload, the resulting downstream record and its customer association.
  4. Ask the receiver owner to demonstrate how a repeated delivery avoids a duplicate downstream record. Record the expected reconciliation method for missing results.
  5. Only after these checks pass, introduce the subscription into the agreed operating process and assign ongoing failure monitoring.

Troubleshooting

ProblemWhat to check
New webhook or editing is unavailableConfirm Administer API configurations and section edit access. This page is not controlled by a case-edit permission.
The URL is rejectedCheck absolute http:// or https:// syntax, host, 255-character limit and pasted spaces. Use HTTPS as the recommended operating choice.
The subscription is a duplicateSearch for the same event and endpoint in this account. Edit the intended existing row instead of adding an identical one.
Contact events are missingThey are not in the current eight-event editor list. Do not follow the old three-webhook article as a current event catalog.
No request appears immediatelyConfirm the actual triggering event, saved subscription and receiver logs. Delivery is asynchronous; a save response is not a delivery receipt.
The receiver rejects authenticationThis subscription has no authentication fields. Resolve the receiver/gateway design or evaluate an appropriate Workflow action; do not paste unrelated credentials into a guessed setting.
Requests arrive but no downstream record existsHave the receiver owner inspect payload parsing, authorization and business-processing results. HTTP receipt and a completed business action are separate checks.
Duplicate downstream records appearReview receiver duplicate handling and overlapping subscriptions or workflows. Do not assume the transport provides exactly-once processing.
Queued work disappeared after deletionDeletion removes pending deliveries for the account/endpoint, including shared subscription deliveries. Reconcile the affected business events with the owners.
  • Configuration → Configure workflows and automation
  • API → Create and manage API tokens

Was this article helpful?