Reactivate an outgoing webhook disabled by WooCommerce

Identify the outgoing notification that stopped

Your store continues recording changes, but the application meant to receive them no longer updates. In WooCommerce, the webhook appears Disabled. A webhook sends an HTTP notification to a delivery address when an event matches the selected topic. This procedure concerns the native notification going from your store to another service. Notifications sent by your payment provider to the store are diagnosed through the payment integration.

WooCommerce may disable a webhook after consecutive failures. The threshold can depend on version and configuration. Start by finding an attempt and its response before reactivating the webhook. If its status is Paused, ask the person who decided on the pause why it was set. An active webhook with no recent attempt calls for checking the topic and task queue.

The expected result includes a new delivery accepted by the correct recipient and evidence that the event was processed as intended. This generally requires WooCommerce settings access and someone able to read the receiving service’s log.

Record the affected webhook’s configuration

In WooCommerce, open Settings, then Advanced and Webhooks. Select the row for the affected integration and record its ID, status, topic, and delivery address. Names may be similar for two stores or environments. Use the ID and topic to identify the correct row, then compare its domain with the one expected by the service owner.

Note the last known change. It may be a recipient migration, secret rotation, path change, or deployment of a new version. Make a private copy of useful settings, keeping secrets in their designated storage. An address may contain a token in its path or parameters. Mask those parts in screenshots and ordinary tickets.

1. Record the installed version, time of the last known events, and environment name.
2. Identify the webhook ID and topic, then confirm who operates its recipient.
3. Record the initial status and the destination intended for rollback.
4. Prepare an isolated copy with notifications and real commercial actions neutralized.

Connect a delivery with the recipient’s trace

In WooCommerce, open Status, then Logs. Filter sources by webhooks-delivery, then search for the webhook’s time and destination. Record the response code, message, and delivery ID when present in the trace. Ask the recipient’s owner to check the same period and event in its own logs. A store-side entry and a receiver-side entry locate the failure much better than status alone.

Logs may contain headers, addresses, and order data. Keep reading private and share only necessary details. Depending on version and settings, the body may not be recorded. Avoid enabling debugging in production to fill out a ticket. Instead, find a nonsensitive example on the copy.

If the log is missing, check retention and logging configuration before concluding that the store sent nothing. If the action is still queued, there may also be no HTTP response to record for that attempt. Use the time and topic to continue diagnosis.

Classify the response before correcting the store

A connection error without an HTTP code and a response issued by the recipient call for different checks. For each, keep the time and look for the trace at the layer that may have responded. A login page, firewall, and application can all return a response at the same URL.

WooCommerce 11.2.1’s current delivery does not enable redirect following in its default parameters. Yet a redirect may be counted as success by the store. A status in this family therefore does not guarantee that the POST reached the final route. Request a direct response from the intended route and confirm receipt in the application.

1. For a 404 or 405, check the path and expected POST method.
2. For a 401 or 403, find the exact rule or verification refusing the request.
3. For a 429, identify the rate limit and affected period before reactivation.
4. For a 5xx or timeout, check server traces and any processing state.
5. For a DNS or TLS error, have access checked from the route used by the store.

Correct the address or rule blocking the route

Open the affected webhook settings and compare the delivery URL with the final URL supplied by the receiver’s owner. Check protocol, domain, path, and necessary parameters. After migration, an old address may respond with a redirect or homepage. Opening it successfully in your browser validates only that read route. The webhook must be able to POST from the store’s network.

For a firewall refusal, ask for the rule ID and verify that it matches this attempt. Adjust only that route’s path or authorization with the owner. Retain signature verification and useful access controls. If the destination certificate is involved, have the certificate received by the store corrected before resuming deliveries.

On the authorized copy, change the Delivery URL field and retain the original topic to isolate this correction. Prepare a test recipient before saving an active webhook. If the new address fails, return to the saved value only if it remains valid and authorized.

Compare the signature before changing the secret

If the receiver reports an invalid signature, first identify the secret associated with this exact webhook and the body actually received. By default, WooCommerce calculates an HMAC SHA-256 over the bytes sent, then Base64-encodes the result in X-WC-Webhook-Signature. Decoding and reencoding JSON can change whitespace, escaped characters, or their representation. Calculate the signature before transforming the body.

This fragment is intended for the developer of an existing PHP receiver using this default algorithm. In its validation function, connect the parameters to the raw body, header value, and effective secret read from private configuration. Use an empty string if the header is missing. The secret must be configured and remain outside code, traces, and responses. A false result must prevent processing of the signed event.

On the copy, check that an authorized event passes and a modified body is rejected. If a secret change is needed, coordinate activation on both sides and retain a rollback procedure with the owner. For a receiver managed by a third-party service, use that service’s designated secret mechanism.

function signature_woocommerce_valide(
    string $corpsBrut,
    string $signatureRecue,
    string $secretEffectif
): bool {
    if ($secretEffectif === '') {
        return false;
    }

    $attendue = base64_encode(hash_hmac('sha256', $corpsBrut, $secretEffectif, true));
    return hash_equals($attendue, $signatureRecue);
}

Correct processing when the receiver already receives the POST

A receiver trace may show that the POST arrived and access verification succeeded, followed by an application error. For example, a changed expected format, failed save, or unavailable internal queue may cause a 5xx response. Find the exact stage in the service trace before changing the WooCommerce topic or secret.

Compare the received payload with the format accepted by the receiver. Reproduce using a synthetic event and test data. If the service processes a task later, ensure that the event is durably recorded before acknowledgment. A response sent too early can mask loss in the recipient’s queue. Conversely, a network timeout may occur after successful processing. In that case, check the business state before considering another send.

If rolling back the recipient to an earlier version, verify that it recognizes the current format and can read data already written. Monitor the same event’s trace. The error message disappearing alone does not demonstrate that the intended update was saved.

Check scheduled actions if no attempt leaves

If the webhook is active and its topic matches a recent event, open WooCommerce, then Status and Scheduled Actions. In the version studied, background processing uses the woocommerce_deliver_webhook_async action and woocommerce-webhooks group by default. Customized installations may use another route. Search for that name and, if details are available, compare the webhook ID and argument with your control.

A pending action may indicate that delivery has not started yet. A completed action indicates that its processing finished from the scheduler’s perspective. Still check the HTTP result and recipient. For a broader delay affecting other actions, use scheduler diagnosis instead of raising the webhook threshold.

1. Search for actions linked only to the affected webhook and record their states.
2. Compare their time with the delivery log.
3. Distinguish a pending queue from an attempt already sent.
4. Before any resumption, check events already processed and actions still present. Avoid bulk reruns.

Reactivate the affected row after correction

Prepare the recipient and verify that the test cannot trigger a real payment, shipment, or message. On the copy, return to WooCommerce, Settings, Advanced, and Webhooks. Open the selected row, confirm its topic and URL, then set its status to Active and save. First activation may trigger a verification request. This ping may differ from a normal event, and its success does not replace evidence that the control was processed.

Once the cause is corrected and behavior validated on the copy, apply the same targeted change according to the store procedure. Check the state after saving. If an error message appears, reread the state actually saved and the receiver trace before trying again. The form may have saved parameters before reporting a ping problem.

1. Confirm the webhook, destination, and effective secret with the owner.
2. Reactivate only the affected row.
3. Record the time and check the first attempts.
4. If the defect returns, pause the row again and examine actions still queued with the operator. A status change does not prove that the queue is empty.

Verify an event of the correct topic end to end

On the copy, produce one event compatible with the webhook topic. For a product-update notification, modify a field of an existing test product. For an order topic, use a fictional order in an environment where real payments, emails, and shipments are neutralized. The control must reach the same type of route and processing as the affected event.

Compare evidence on both sides. Record the delivery’s HTTP status and object ID, then find the corresponding recipient trace. Also check the state after processing. If the application adds the event to its own queue, wait for processing and confirm the intended update. The route’s response does not replace this check.

On the public store, check the next normal events through their logs. If the first attempts succeed and updates follow, continue monitoring the relevant topic. If the counter begins accumulating failures again or the recipient ignores events, return to the stage indicated by traces.

Reconcile missed events before any resend

Reactivation restarts the normal flow of future events. For the period when the webhook was stopped, establish what the store changed and what the other service actually received. An apparently failed attempt may have been processed before its response was lost. An action may also remain pending. Compare business IDs, event types, and states, accounting for times and subsequent updates.

Choose the recipient’s documented procedure for filling gaps with its owner. Synchronizing current state may suffice for a catalog. Transition-sensitive processing requires checking the order and effects of every event before replaying it. The deduplication key must suit this processing. The same product can have several legitimate updates.

1. Define the period and affected resources.
2. Separate confirmed, missing, and still-uncertain items.
3. Check pending actions before any targeted resend.
4. Check the recipient-side result after each sensitive catch-up operation. Keep a record of decisions and the person who approved them.

Prevent another stop after migration or rotation

In the store’s operations record, document each webhook’s owner, topic, recipient, and secret-management channel. After migration, confirm the final address and POST processing with the service owner. During secret rotation, choose a time window and plan coordination at both ends. Verify the first valid event after the change.

The webhooks described are part of the free WooCommerce module, with version 11.2.1 used as this guide’s reference. Third-party receiver terms depend on the contract already in use. For this troubleshooting, first check the log, destination, and existing receiver configuration. Changing the threshold may delay the next stop while leaving the cause of failures intact.

Keep traces allowing deliveries to be correlated without copying customer data. When the recipient performs sensitive operations, record how to check their state before replaying an event. If the incident returns, give the owner the webhook ID, time, status, and exact stage where the trace stops.

Prepare three controls before reactivating the webhook

On the isolated copy, prepare three receiver checks using synthetic data. The first sends a body signed with the test secret: the recipient must record the event before confirming acceptance. The second changes one body byte without recalculating the signature: it must be rejected before any business effect. The third represents repeat delivery of the same event under the receiver’s contract: it must not cause an effect intended to be unique twice.

These checks must trigger no real shipment, charge, or message. Keep only synthetic identifiers, status, and resulting state; no secret or real order body is needed in the report. This guide’s verification function covers signatures, not deduplication or the processing queue: their storage and key belong to the receiver.

A key based solely on the product ID can suppress legitimate successive updates. Define uniqueness using the event type, delivery identity, or synchronization contract actually employed. Also plan for late arrival of an old state before replaying a batch.

After correction, reactivate only the affected row and correlate the first normal delivery with the recipient’s final state. A 2xx hiding lost processing is not complete validation. If the test fails, pause the webhook again and check the remaining queue; pausing does not undo effects already produced. WooCommerce’s free native features suffice for sending, while the receiver’s cost and contract must be assessed separately.