SupportCandy Webhooks - WordPress Plugin

SupportCandy Webhooks Setup Guide for Support Automation

SupportCandy Webhooks is not there to decorate the ticket form. Its purpose is to connect your support desk to external systems: a CRM, spreadsheets, chat tools, your own app, incident analytics, or an internal task router. In this guide, we will break down how to plan webhooks, which events to choose, how to set up secure delivery, how to validate the incoming request, and what to do if the notification never reaches its destination.

This guide is written for WordPress site owners, support administrators, and developers who need to get data out of SupportCandy without manual exports. It does not cover purchasing, license activation, or workarounds for product limitations. We assume your core SupportCandy setup is already working, and the goal here is to connect ticket events to an external workflow cleanly and safely.

The core idea is simple: a webhook sends an HTTP request to a specified URL when a selected event happens inside the support system. The real value appears only when the overall flow is designed correctly: which trigger is used, what data the receiving system expects, how the signature is verified, where to inspect logs, and how to avoid turning every agent reply into noise for the entire team.

Where webhooks actually help a support team

A webhook is useful wherever a regular email or a ticket list view is not enough. Email notifications work well for people, but not for automated processing: you have to parse them, handle forwards, attachments, signatures, and different email templates. A webhook sends a structured request to a predefined endpoint, so the external system can immediately decide what to do with the event.

SupportCandy Webhooks includes several confirmed triggers: ticket creation, status changes, assignee changes, ticket closure, ticket replies, private notes, changes to subject, category, priority, ticket fields, agent-only fields, and the Out of SLA event. That set makes it clear the product is built not just for "new ticket" notifications, but for the full lifecycle of a support request. That is why it makes more sense to treat it as a bridge between your help desk and external processes, not just another notification channel.

Common real-world use cases:

• Send a new ticket to a CRM or internal request registry so the manager has a unified customer profile.
• Notify a support channel when a ticket becomes urgent, changes priority, or goes out of SLA.
• Send ticket closure events to an analytics system to measure response speed and repeat contact rates.
• Sync an internal agent field with an external quality-control tool without exposing that field to the customer.
• Trigger your own handler that verifies the signature, filters the event, and only then forwards the data elsewhere.

The strongest SupportCandy Webhooks use case is not blasting out everything in bulk, but building precise automation around meaningful ticket changes. If a person simply needs to see the event right away, email or a Slack integration may be enough. If the event needs to land in a database, queue, report, external API, or custom business logic, a webhook is usually the better fit.

Who this product is a good fit for

This plugin works well for sites where SupportCandy has already become the main place for communicating with customers, but support operations do not live entirely inside WordPress. That includes ecommerce stores, SaaS products, agencies, education platforms, service companies, internal portals, and any team that needs to connect tickets with outside context. The value becomes especially clear when a support request has a next step outside WordPress: create a task, update a customer record, write to a log, run an SLA check, or alert an on-call engineer.

SupportCandy Webhooks is also useful for developers who need a controlled outbound channel. Unlike a custom integration built with arbitrary WordPress hooks, this setup lets the administrator manage the delivery URL and event list directly from the plugin interface. That makes it easier to maintain: you can disable a specific webhook, change the URL, rotate the secret, and inspect logs without editing site code.

When another approach makes more sense

If you need a multi-step workflow like "if A and B happen, wait, check a condition, then run several actions," a webhook alone may not be enough. In that case, look at SupportCandy Workflow/Automations, external automation platforms, or a dedicated event-processing service. If all you need is a human-readable alert for a new request, it is usually easier to set up an email notification or a purpose-built integration such as Slack, where you may already have a reply flow inside a thread.

Another important case is having no receiver at all. SupportCandy Webhooks sends the request, but it does not replace the server that accepts, validates, and processes that request. If you do not yet have an external endpoint, a CRM webhook, an automation service, or your own script, build the receiver first. A temporary webhook capture service is fine for testing, but production data should go through infrastructure you control.

What to check before installation and first launch

Before configuring webhooks, verify not only that the extension itself is available, but that the whole chain is ready. Failures often come not from SupportCandy, but from the receiving URL, blocked outbound requests, an incorrect secret, payload changes before signature verification, or an overly broad trigger selection.

Basic site readiness

SupportCandy should be installed, activated, and configured well enough that tickets are actually being created, agents are being assigned, statuses are changing, and the required fields are in use. If the core help desk setup has not been validated yet, webhook troubleshooting becomes harder because you will not know whether the issue is with the event, the ticket configuration, or request delivery.

For WordPress plugins like this, permissions matter. The "assignee change" trigger is useless if you have not created agents and roles yet. Triggers based on ticket fields and agent-only fields require those fields to exist and to actually change inside the ticket. The Out of SLA event only makes sense if SLA logic is already configured. Do not enable everything in advance "just in case." First make sure the core feature behaves predictably.

Receiving URL readiness

The Delivery URL must be externally reachable, accept HTTP requests, avoid interactive authentication, and respond quickly. If the external system processes data slowly, it is better to accept the request, save it to a queue, return a success response, and do the heavier work separately. That keeps the webhook from depending on a slow operation.

For validation, use a temporary test endpoint that shows request headers, body, and response code. That helps you see the actual payload structure, confirm that the selected trigger fired, and identify which header carries the signature. But do not leave a temporary service in production settings: the request may contain customer data, ticket subject lines, email addresses, internal fields, or message excerpts.

Practical check: before connecting a CRM or your own handler, create a separate test webhook with a safe endpoint, perform a single action in a test ticket, and confirm that you can see the request, headers, body, and response status.

Security, access, and customer data

Webhooks often carry data you should not expose to unnecessary systems. Decide in advance which events the external receiver actually needs. For example, a private note event may be useful for internal quality control but unnecessary for a CRM. A change to agent-only fields may include internal operational data that is not meant for the customer and should never reach public channels.

If you add a secret key, the receiving side should verify the signature. SupportCandy documentation states that the signature is sent in the X-WPSC-Webhook-Signature HTTP header as a base64-encoded HMAC-SHA256 of the payload. That matters more than it may seem: without signature verification, any outside sender could theoretically try to imitate a request to your endpoint.

Also verify who on the team is allowed to change webhooks. The delivery URL, secret key, and selected events are not cosmetic settings. A mistake there can send data to the wrong destination, stop automation, or create duplicate events.

Installing the extension and running the first check

The core SupportCandy plugin can be installed from the WordPress plugin directory or uploaded manually through the Plugins screen. The Webhooks extension is one of SupportCandy's add-ons, so the main plugin must already be installed in the admin area and the corresponding add-on must be activated. Exact screen names may vary depending on your add-on set, but the working order stays the same: first the main help desk, then Webhooks, then the configuration of a specific endpoint.

What to do after activation

1. Make sure the main SupportCandy section is available in the WordPress admin panel.
2. Open SupportCandy settings and find the Webhooks section.
3. Create a separate test ticket so you do not use real customer requests.
4. Prepare a temporary or internal endpoint that displays the incoming request.
5. Create your first webhook with only one trigger, such as ticket creation.
6. Save the configuration, perform the action in the test ticket, and open the delivery log.

Do not start with five different triggers and a live CRM. If the request does not arrive, you will have to check the event, URL, firewall, payload format, permissions, SSL, signature, and the receiver's processing logic all at once. One simple trigger tied to a test ticket cuts troubleshooting time dramatically.

The first real success criterion

Your first successful run is not "the webhook was created." Success means the full chain worked: the event happened in SupportCandy, the outbound request appeared on the receiver side, the logs show a valid response, the payload includes the data you expected, and the receiving side can distinguish the test event from a real customer request. If you have not checked the payload, you do not actually know which fields are available for the next stage of the integration.

At this stage, it helps to create a simple scenario table: trigger, action in the test ticket, expected request, expected response, and next step. That table will be useful not only during setup, but also after updates when you need to confirm quickly that the integration still works.

Detailed setup: name, Delivery URL, triggers, and secret

The webhook settings screen contains only a few simple fields, but each one affects long-term maintainability in production. A bad name creates confusion in the list, a bad URL breaks delivery, too many triggers create unnecessary noise, and no secret makes secure processing harder. Below is a practical setup order that helps you configure a webhook you can still understand and maintain months later.

Webhook Name: name it by event and receiver

The webhook name should explain not just the event, but also the destination. Bad names: Test, CRM, Webhook 1. Good names: New ticket to CRM staging, High priority ticket to incident router, Closed ticket to support analytics. Once you have several integrations in the list, names like these make it much easier to see what can be disabled safely.

If you have both a test and a production endpoint, do not combine them in one webhook. Create separate entries and label the environment clearly. That reduces the chance that test tickets will reach the live CRM or that real support requests will end up in a temporary receiver.

Delivery URL: validate availability and stability

In the Delivery URL field, enter the address where SupportCandy should send requests. Use HTTPS for production data. Make sure the endpoint does not redirect to a login page, block requests by user agent, or depend on an admin cookie session. A webhook should be a machine-facing entry point, not an admin screen.

If the external system provides separate endpoints for testing and production, start with the test one. After validation, switch the configuration to the live URL and run another control event. Do not assume "the test and production URLs behave the same." Different domains, certificates, firewall rules, and payload limits can behave differently.

Triggers: choose the event based on business meaning

SupportCandy Webhooks offers a set of triggers tied to key ticket actions. Your selection should depend on what the external system needs to do.

After choosing your triggers, ask yourself: "What happens if this event occurs ten times in one minute?" If the external system will create duplicates, spam a channel, or overwrite the same field repeatedly, you need extra filtering on the receiving side.

Secret Key: enable it anywhere data is processed automatically

The secret key in webhook settings is used to verify request authenticity. SupportCandy generates a signature from the payload and sends it in the X-WPSC-Webhook-Signature header. The receiving side must calculate the same signature with the same secret and compare the results. If the signature does not match, the request should be rejected and no business action should run.

Do not store the secret in a public repository, inside your WordPress theme, or anywhere customer-facing code can expose it. Keep it in environment variables, server secrets, protected application settings, or another secure store. If you suspect the secret has leaked, rotate the secret key in SupportCandy and in the receiving handler at the same time.

Minimal PHP example for signature verification

This snippet belongs only on the receiving side, not inside SupportCandy. It shows the core verification pattern: take the raw payload, compute HMAC-SHA256 with the same secret, and compare it to the header. In a real project, also add logging, request method validation, and proper error handling.

<?php
$payload = file_get_contents('php://input');
$secret = getenv('SUPPORTCANDY_WEBHOOK_SECRET');
$received = $_SERVER['HTTP_X_WPSC_WEBHOOK_SIGNATURE'] ?? '';

$expected = base64_encode(
    hash_hmac('sha256', $payload, wp_specialchars_decode($secret, ENT_QUOTES), true)
);

if (!$secret || !$received || !hash_equals($expected, $received)) {
    http_response_code(401);
    exit('Invalid webhook signature');
}

http_response_code(200);
echo 'OK';

The post-deployment check is simple: send a test event with the correct secret, then temporarily change the secret on the handler side and make sure the request gets rejected. After the test, restore the correct value. This confirms that the endpoint is not just accepting any POST request, but is actually validating the source.

How to build the "ticket - webhook - external system" flow

A webhook by itself is not a complete integration. It only delivers the event. The integration begins when the receiving side understands the payload, validates the signature, stores an event identifier, and performs the action without creating duplicates. This is especially important with SupportCandy because a single ticket may stay active for a long time: the customer replies, the agent adds a note, the status changes, the priority is raised, the ticket is closed. If every event creates a new record without filtering, the external system quickly turns into a junk log.

Minimal handler architecture

Even a small handler is worth structuring in four layers:

1. Request intake: validate the method, body size, content type, and basic reachability.
2. Security: verify X-WPSC-Webhook-Signature and reject requests without a valid signature.
3. Normalization: parse the payload and extract the ticket ID, event type, status, priority, assignee, and the fields you need.
4. Action: update an existing record, create a task, send a notification, or place the event in a queue.

If the external system supports upsert, use the ticket ID as the stable key. That way, a status change updates the existing record instead of creating a second one. If different events include different fields, the handler should be tolerant: a missing optional field should not break the whole process.

Why sending everything straight to the final service is often a bad idea

You can point the Delivery URL directly to an external service, such as an automation platform or CRM URL. That is fast, but not always flexible. An intermediate handler gives you more control: it validates the signature, strips unneeded data, hides internal fields, maps status names, protects against duplicates, and writes its own logs. That layer is especially useful if SupportCandy contains personal data, agent-only fields, or different receivers for different ticket categories.

A small team can start with a direct endpoint, but the limitations should be documented from day one. If duplicates appear, statuses change frequently, security requirements tighten, or routing becomes more complex, it is better to move processing into a separate service.

Ticket triggers: how to avoid noise and duplicates

Support operations run on events, but not every event deserves external automation. When configuring SupportCandy Webhooks, it helps to divide triggers into three groups: starting events, process events, and control events. That makes it easier to choose the minimum useful set and avoid overloading the external system.

Starting events

Create Ticket is usually the most straightforward trigger. It creates the starting point for an external record: a new support lead, a new line in a report, or a new task in an incident-control system. For this trigger, it is important to preserve the original ticket ID, subject, category, priority, author, and ticket URL if it appears in the payload or can be generated by the handler. Without a stable ID, later synchronization becomes unreliable.

If guest tickets are enabled on your site, check separately which data is available for guest users. Do not assume the payload always looks the same for registered users and guests. Test both scenarios if both are allowed on your site.

Process events

Change Status, Change Assignee, Reply to Ticket, Change Ticket Priority, and similar triggers help keep the external system up to date. But these are also the triggers most likely to create noise. For example, if an agent changes the status after every reply, the external channel may receive dozens of notifications for the same request.

The fix is to filter by meaning. Not every status change needs to go to Slack or the CRM. You can accept all events at your endpoint, but only forward the important ones: a move to "High," assignment to a specific group, an SLA breach, closure after resolution, or a customer reply on a high-priority ticket.

Control events

Out of SLA and events based on agent-only fields are often more important than ordinary replies. They reflect the internal state of the support operation: overdue requests, escalations, technical classification, or a manual decision by an agent. These events should be designed carefully. If an agent-only field contains an internal diagnosis, it should not be sent to a public spreadsheet. If Out of SLA should create an incident, make sure the SLA rule fires only once or that the external handler can suppress repeats.

Configuration rule: start with one starting trigger and one control trigger, then add process events only after analyzing real ticket flow.

Agent-only fields, ticket fields, and private notes in integrations

SupportCandy can work with more than the standard ticket fields. Ticket fields extend the ticket itself and may be visible to the user depending on visibility settings. Agent-only fields serve a similar purpose, but are meant for internal team data. The documentation, however, specifically warns that if you add them to customer ticket list items, customers may see those fields in the list. That is an important nuance for webhooks, because an "internal field" does not always automatically mean "never exposed externally."

What to send to external systems

If the integration is for a CRM, it usually only needs the ticket ID, contact, subject, category, status, and final classification. If the integration is for internal analytics, you may send more: priority, agent-only classification, response time, and closing status. If the receiver is a public chat or sales channel, send the minimum and avoid private notes.

Before enabling the Submit Private Note and Change Agentonly Fields triggers, run a quick audit:

• Which fields may contain personal data, internal customer assessments, or technical secrets.
• Who has access to the external system that will receive the request.
• Whether email addresses, phone numbers, internal comments, or attached links should be masked.
• Whether you can replace a detailed payload with a short event such as "escalation required," "waiting for engineer," or "closed after verification."

How to use fields without leaking unnecessary information

A safe strategy is to send the full request to your external endpoint, but not forward it as-is beyond that point. The handler should pick only the values that are actually needed. For example, your CRM may only need the category and ticket number, while the private note stays in a protected internal log. An on-call channel may receive the status, priority, and ticket link, but not the full message thread.

If the external system does not support flexible data filtering, it is better to create an intermediate handler. It receives the webhook from SupportCandy, verifies the signature, sanitizes the payload, and builds a safe outbound message. That is not architecture for architecture's sake. It is a practical safeguard against accidentally exposing internal data.

Practical example: sending critical tickets to an external handler

Let's walk through a scenario technical support teams often need: a new ticket or a priority change should be sent to an external handler, and that handler then decides whether to create an incident, notify the on-call engineer, or simply update the CRM. We will not tie this to a specific SaaS product, because every team uses different tools. What matters here is understanding the flow and the validation points.

Goal

The goal is a controlled integration: SupportCandy sends the event, the endpoint verifies the signature, extracts the ticket ID and priority, logs the event, and forwards only critical requests. As a result, the team sees only meaningful signals instead of every reply in the conversation.

Preparation

• SupportCandy includes a test ticket, categories, and priorities.
• The Webhooks add-on is enabled and the Webhooks section is available.
• A test endpoint is available that shows incoming headers and request body.
• The production endpoint already has a secret key and an error log.
• The team has agreed on which statuses and priorities count as critical.

Setup steps

1. Open SupportCandy settings and go to the Webhooks section.
2. Click Add New and enter a clear name, for example Critical ticket events to incident router.
3. In the Delivery URL field, enter the test endpoint, not the production URL yet.
4. Select the Create Ticket trigger and save the webhook.
5. Create a test ticket with safe sample data.
6. Confirm that the endpoint received the request and that SupportCandy logs show a delivery record.
7. Add Change Ticket Priority, change the priority of the test ticket, and inspect the payload again.
8. Add the secret key, update the receiving endpoint, and verify the X-WPSC-Webhook-Signature header.
9. Switch the Delivery URL to the production endpoint and repeat one control test.

Expected outcome

After setup, a new ticket generates an outbound request, a priority change generates a separate event, and the receiving side sees the signature, the payload, and can match the event to a specific ticket ID. If the endpoint filters by priority, only the requests that truly need attention are forwarded into the final system.

A common nuance that gets in the way

If the priority is changed automatically through a workflow or another extension, the event may fire without any manual action by the agent. That is normal, but it requires duplicate protection. The handler should recognize that the ticket has already been sent as critical and avoid creating a new incident every time it is saved again.

Rollout plan for a test site before production

Webhooks are best introduced not as a one-time setting, but as a small implementation project. That is not bureaucracy. SupportCandy Webhooks connects real customer requests to external systems, so one mistake can multiply quickly. One incorrect trigger can create dozens of duplicates, one open endpoint can accept a spoofed request, and one overly broad payload can send a private note where nobody should ever see it.

Below is a practical rollout plan for a site without a dedicated engineering team. You can run it on a staging copy, a private test site, or even on the live site using safe sample tickets if no staging environment exists. The important part is not to start with real customer requests and not to connect the final CRM before an intermediate validation step.

The "event map" phase

Start by listing the events you actually need. Do not treat the trigger list as a task list. Every event should have a receiver, an action, and a success criterion. For example, Create Ticket creates a CRM record, Change Ticket Priority updates an urgency field, and Out of SLA creates an internal incident. If you cannot define the action for a trigger, do not enable it yet.

For each event, define which data the receiver needs. In many cases, the external system does not need the full payload. The ticket ID, subject, status, priority, customer email, and a link to the ticket may be enough. A list like this helps you design filtering early and avoid sending unnecessary fields.

The "safe endpoint" phase

Before the production endpoint, use a safe receiver. That can be a temporary testing service or your own internal route that only logs the event for now. At this stage, the goal is to see the actual headers, request body, response code, and SupportCandy log behavior. Do not try to create deals, tasks, or incidents in the final system yet.

If the payload contains personal data, do not forward it to public debugging tools. An internal endpoint with short log retention is safer. For every test, record the action in the ticket, the selected trigger, delivery status, endpoint response, whether the signature was present, and a short conclusion.

The "filtering and duplicate protection" phase

Once the payload is understood, add filtering. For example, you may always log a new ticket, but only notify the on-call engineer when the priority is high. A status change may be accepted into the log, but forwarded to the CRM only if the new status is actually meaningful to the business. This kind of filtering is best handled on the receiver side, because it is easier to update and does not require changing every webhook setting.

Duplicate protection should exist before production, not after the first incident. The minimum logic is simple: if an external object already exists for the ticket ID, update it instead of creating a new one. For SLA events, add a rule that prevents opening a second identical incident while the first one is still open or the ticket status has not changed.

The "production delivery and rollback" phase

After testing, switch the Delivery URL to the production endpoint and run one control scenario. Do not change the triggers, secret, endpoint, and filters all at once. If something breaks, you will not know which change caused it. Change one thing, verify the result, and only then move to the next step.

For rollback, keep three things documented: the previous Delivery URL, the previous trigger set, and the exact place where the webhook can be disabled. If the external system starts receiving unwanted events, the administrator should be able to stop delivery quickly without waiting for a developer. After stopping it, review the logs and the endpoint journal, then restore the integration one event at a time.

Readiness criterion: the integration is ready for production when the team can repeat the test, see the request in the logs, explain every selected trigger, verify the signature, and disable the webhook safely if something goes wrong.

Verifying the result and working with logs

SupportCandy documentation highlights webhook logs as the place to inspect requests and responses. This is your main diagnostic tool. Without logs, an administrator only sees the external consequence: "nothing showed up in the CRM" or "the channel is silent." Logs help you understand whether the request was sent at all, what response the endpoint returned, and where the chain actually failed.

What to look for in logs

After each test event, check three things. First, whether a delivery record exists. If there is no record, the trigger did not fire or the webhook is not active. Second, which status the Delivery URL returned. A successful HTTP response does not always mean the business action completed, but a 4xx or 5xx error definitely points to a problem on the receiving side. Third, whether the event time matches the action you just performed in the ticket. That helps distinguish an old attempt from the current one.

If the log shows successful delivery but the external system stays silent, look for the error after the endpoint: priority filtering, incorrect status mapping, duplicate suppression, queue processing, internal authorization, or an external API limit. If the log shows a failure, start with the URL, SSL, request method, secret key, and signature format.

Post-setup validation checklist

• A test ticket was created and the first request was received.
• The payload was checked for every selected trigger.
• The secret key was enabled and verified, and the signature rejects invalid requests.
• The external endpoint returns a clear HTTP status and writes its own log.
• Duplicate events do not create duplicate records in the external system.
• Personal and agent-only data is not being sent to unnecessary channels.
• The team has instructions on where to disable the webhook and where to inspect errors.

Quick recap: the setup is only complete after you have verified delivery, signature validation, payload contents, filtering, logs, and rollback. One successful request without inspecting the body is not a finished integration.

Limits, performance, and security

Webhooks are convenient, but they do not eliminate engineering constraints. SupportCandy Webhooks gives you a clear trigger set, a signature secret, and logs, but the reliability of the overall integration still depends on the receiving endpoint, the network, the external API, and how you handle repeat events. Do not promise the team "guaranteed delivery" unless you have your own queueing and retry logic in place.

Endpoint response speed

If the receiver is slow, hangs, or periodically returns errors, the webhook becomes a weak point. The practical architecture is to accept the request quickly, verify the signature, store the event in a queue or log, and return a response. After that, a separate process can send the data to the CRM, spreadsheet, or channel. This reduces WordPress's dependence on external services.

Updates and compatibility

The extension changelog has included fixes related to add-on updates, compatibility with the Merge ticket feature, URL encoding for Power Automate, and actions inside the settings panel. This is a good example of why you should run a short webhook regression test after updates. That matters especially when the Delivery URL contains special characters, percent signs, query strings, or is used with automation services.

Do not publish real secrets, tokens, application passwords, or customer-facing endpoints in an article or public documentation. If you need an example, use safe placeholder values and store the real production variables separately.

REST API and webhooks are not the same thing

SupportCandy also has REST API documentation. That is a different integration model. A webhook tells an external system that an event has happened. A REST API lets the external system request data, create a ticket, or retrieve object lists when it has authorization. In many setups, they work together: the webhook sends the ticket ID, and the handler then uses the API to request additional data if needed and permitted.

REST API access requires separate authentication. SupportCandy documentation states that the API is available to registered users and requires authentication. WordPress, in turn, supports application passwords for Basic Authorization over HTTPS, although more secure production-grade schemes are often considered. Do not treat the webhook secret key as REST authentication. They are different security mechanisms for different sides of the exchange.

When to use Workflows, Slack, or the REST API instead of a webhook

SupportCandy Webhooks solves the problem of outbound notifications to an external system, but the broader SupportCandy ecosystem includes adjacent tools. The key is not to choose the most technical option, but the most appropriate one.

Workflow/Automations

Workflow/Automations in SupportCandy operates inside the ticketing system itself: triggers, conditions, and actions let you automatically change status, assign an agent, add a private note, or update fields. If all the logic should stay inside SupportCandy, workflow is often a better fit than a webhook. For example, "if priority is High, assign the senior team and add a private note" does not necessarily need to be sent to an external endpoint.

You need a webhook when the action has to go beyond WordPress or when the external system becomes the source of the next step. In many cases, the best option is a combination: workflow normalizes ticket state inside SupportCandy, and webhooks send only the important events outward.

Slack Integration

SupportCandy's Slack integration is designed for channel notifications and, if configured correctly, the ability to reply from a thread. If your team's goal is to spot a new ticket quickly and continue discussion in Slack, the dedicated integration is more convenient than a custom webhook. But if you need to send data to multiple systems, filter the payload, verify signatures, and build your own routing logic, Webhooks remains the more flexible choice.

REST API

Choose the REST API when the external system needs to fetch or create data on demand. For example, a nightly report may pull the list of tickets through the API instead of waiting for a webhook. But for an event like "this ticket just went out of SLA," the API is less convenient because it would require polling the site, while a webhook reports the event immediately. In larger integrations, these approaches often complement each other.

Safe improvements without editing the plugin core

With SupportCandy Webhooks, you should not edit plugin files just to "add one more field" or change the delivery behavior. Those edits will be lost during updates and may break request delivery. It is safer to improve the external side instead: the endpoint, queue, log, filtering, and processing rules. That gives you control without touching the WordPress or SupportCandy core.

Logging on the receiving side

The minimum safe improvement is to log every accepted event separately, including the ticket ID, trigger type, timestamp, signature verification result, and final action. Do not keep full payloads forever if they contain personal data. For debugging, a short retention period and a temporary verbose mode are usually enough.

Idempotency instead of fighting duplicates manually

Idempotency means a repeated event does not break the result or create extra records. For webhooks, that is a practical rule: the external handler should be able to recognize that the ticket already exists in the CRM or that the incident was already created. Use the ticket ID, event type, and current state instead of a simplistic "every request creates a new row" approach.

Soft rollback

Before changing the production Delivery URL or the trigger set, save the old value in protected team notes. If the external system starts receiving duplicates or stops accepting requests after the change, rollback should take minutes, not hours. Do not delete the webhook right away. It is usually better to disable it temporarily or restore the previous endpoint, then investigate the root cause in the logs.

Why the webhook is not firing or not getting through

The best way to troubleshoot is to follow the chain: ticket event, webhook settings, outbound request, endpoint response, external-system processing. If you jump straight to the CRM, you can miss the obvious problem: the wrong trigger, an inactive webhook, a bad URL, or a failed signature check.

No delivery record appears in the logs

Symptom: you created or changed a ticket, but no new attempt appears in the webhook logs. A likely cause is that the selected trigger does not match the action, the webhook was not saved, the add-on is not active, the test is happening on the wrong site, or the event depends on a feature that has not been configured yet.

Check that the action truly matches the trigger. For Change Assignee, you must actually change the assignment, not just open the ticket. For Out of SLA, the SLA conditions must already be configured. For agent-only fields, you must change that specific field and have the necessary permissions.

The request arrives, but the external service returns an error

Symptom: the logs show an attempt, but the endpoint response indicates a failure. In most cases, the issue is on the receiving side: the wrong route, bad authorization, payload size limits, disallowed method, SSL failure, firewall restriction, or an expectation of a different data format.

First, point the same webhook to a test endpoint and compare the actual payload to what the external service expects. If the service requires a strict JSON format, you may need an intermediate handler that converts SupportCandy data into the required schema.

The signature does not match

Symptom: the endpoint receives the request, but your X-WPSC-Webhook-Signature verification rejects it. Check the secret key, the HMAC-SHA256 algorithm, the base64 format, the original raw payload, and whether the server changes the request body before verification. You cannot compare a signature calculated from already-parsed JSON if the original signature was calculated from the raw request body.

If you use a proxy, load balancer, or middleware, make sure it does not alter encoding or strip headers. For temporary troubleshooting, you can log the raw payload length, the presence of the header, and the computed result, but do not publish the secret or the full payload in publicly accessible logs.

Events create duplicates

Symptom: one ticket appears multiple times in the external system. The cause is usually that several triggers lead to the same action, the handler always creates a new record, or an automated workflow changes a field repeatedly.

Fix: use the ticket ID as the key, store the last processed state, and update instead of create. If an incident should only be created once, add a flag on the external-system side or in your handler's own table.

Extra or sensitive data is being sent into a channel

Symptom: a Slack channel, spreadsheet, or CRM receives a private note, an agent-only field, or personal information the receiver does not need. The cause is forwarding the payload without filtering.

Stop the webhook or redirect it to a safe endpoint, then add a filtering layer. Roll back the public message if possible and review the trigger set. For private notes and agent-only fields, it is better to use a separate protected receiver instead of a shared channel.

After an update, a URL with percent signs or parameters stops working

Symptom: the Delivery URL used to work, but after an update or a change in the external service it no longer accepts requests. The Webhooks changelog included fixes related to URL encoding for Power Automate, so URLs with special characters should be tested separately.

Check the URL in plain form, remove any extra spaces, compare the test and production endpoints, and then run a control event. If the URL includes complex parameters, it is better to keep critical tokens on the receiver side instead of placing them in a long query string.

When SupportCandy Webhooks is the right choice

SupportCandy Webhooks is a strong choice if SupportCandy is already running on your site and you need to push important ticket events into an external system without manual export and without editing the plugin core. The extension is especially effective when you already have a clear receiver in mind: a CRM, incident router, analytics platform, internal log, automation service, or your own endpoint with signature verification.

Before going live, follow a short path: one test webhook, one trigger, payload validation, secret key enabled, logs reviewed, data filtering in place, and duplicate protection added. After that, you can connect additional events. This approach is slower than "turn everything on," but it saves time during troubleshooting and reduces the risk of exposing unnecessary information.

If you are ready to validate the integration with a test ticket and already know which events should go out, you can download SupportCandy Webhooks and move on to configuring it on your site. Start with a safe endpoint, never publish secrets, keep the logs close, and document exactly why each webhook exists.