Reliable WordPress Webhooks: Signatures, Retries and Duplicate Events

A migrated website can look finished while its integrations are quietly losing information. A booking notification reaches WordPress twice, an order update arrives before the original order event, or a CRM request times out after the remote service has already accepted it. These are ordinary distributed-system problems, not exotic failures. Webhooks make two independent systems communicate over a network that provides no guarantee of convenient timing. When moving an AI-built interface to WordPress, rebuilding those connections means designing for duplicate delivery, delayed responses and partial success. The endpoint's happy-path demonstration is only the beginning of the operational design.

Write the event contract first

List the events the receiving site needs and the action each event should trigger. A customer update is different from an instruction to create a customer, even when their payloads look similar. Record the provider's event identifier, payload version, timestamp and any resource identifier used to fetch current state. Decide whether the payload is authoritative or whether it merely signals that authoritative data should be requested. Keep this contract narrow. Subscribing to every event offered by a platform increases noise and processing cost without necessarily improving the integration. An explicit contract also makes later provider changes easier to assess.

Verify the original request bytes

Signature verification generally depends on the exact request body and the provider's documented signing procedure. Parsing JSON and serialising it again can change whitespace or key ordering, producing a different byte sequence. Read the raw body, validate the signature as documented and only then interpret the data. Where the scheme includes a timestamp, enforce an appropriate tolerance and keep server clocks accurate. Use constant-time comparison where the verification implementation requires it. A WordPress nonce is not a replacement for a provider signature: nonces support specific WordPress request contexts, not authentication of arbitrary external webhook senders.

Separate receipt from processing

An endpoint should do enough work to authenticate the event, validate its basic structure and store it durably before acknowledging receipt. Heavy downstream activity can then happen through a queue. A successful response sent before durable storage creates a gap: the sender may stop retrying even though the receiving site loses the event immediately afterwards. Conversely, doing everything inside the request makes provider timeouts more likely. Use the provider's expected response conventions and an established background-processing mechanism appropriate to the site. The precise acknowledgement point matters more than shaving a few lines from the handler.

Make duplicate delivery harmless

Most useful webhook integrations should assume at-least-once delivery, meaning the same event can arrive more than once. Store a provider-scoped event identifier with a uniqueness constraint so competing requests cannot both claim the same event. A simple read-then-write check is vulnerable to a race. Track processing states such as received, running, completed and failed, with enough information to retry safely. Duplicate receipt is not the same as completed processing: an event first stored during an outage may still need work. Idempotency means repeating the operation has the intended net effect, not merely that a log entry exists.

Expect events to arrive out of order

The latest event received is not necessarily the latest business state. Network retries and separate delivery queues can reorder notifications. If the provider exposes resource versions or reliable update timestamps, use them to reject stale changes where appropriate. Alternatively, fetch the current resource state and reconcile it instead of blindly applying every historical payload. This is especially important for subscription status, availability and access rights. An old activation event must not reopen access after a newer cancellation. Document which transitions are valid, rather than assuming every incoming event is an instruction that should be applied immediately.

Retry with limits and useful timing

A temporary network failure can justify another attempt; an invalid credential usually needs an operator to intervene. Classify failures before retrying them. Apply increasing delays with some randomness so multiple failed jobs do not all return at the same instant. Respect documented rate limits and retry instructions from downstream services. Set an attempt limit and a place for exhausted jobs to wait for review. Endless retries hide permanent failures and create avoidable load. Retain enough context to explain the last error, but do not copy entire sensitive payloads into routine logs just because doing so makes debugging convenient.

Handle partial success explicitly

Suppose a job creates a CRM contact and then fails while adding a tag. Retrying the entire job must not create another contact. Use a stable external reference and supported idempotency keys when the remote API offers them. Store the remote identifier once it is known, then resume from the missing operation. When a request times out after transmission, the result may be unknown rather than failed. Querying the remote system by reference can resolve that uncertainty. Distributed workflows often need reconciliation rather than rollback; a clear record of completed steps makes that reconciliation practical instead of speculative.

Protect logs and stored payloads

Webhook bodies can contain names, email addresses, addresses or commercial information. Store only what the integration needs, restrict access and define retention. Operational logs should usually contain event IDs, statuses and error categories rather than full personal records. Never expose signing secrets through a debug page or a browser bundle. When rotating credentials, follow the provider's supported overlap procedure if available so valid deliveries are not rejected during the change. Distinguish the incoming signing secret from outbound API credentials. They have different purposes and should not become one shared secret simply because they belong to the same integration.

Give operators a recovery path

An integration becomes maintainable when someone can see that it has stopped progressing. Monitor the oldest waiting event, repeated failures and the gap between received and completed work. A manual replay action must preserve the same idempotency rules as automatic delivery. Provide a reconciliation job that compares important remote records with local state, particularly for events affecting entitlements or paid orders. A missing notification should be detectable without waiting for a customer complaint. During migration, keep a record of the cutover boundary so events delivered to the old endpoint can be reconciled with those delivered to the new one.

Test the awkward cases economically

Use provider fixtures or a controlled test environment to exercise one duplicate event, one invalid signature, one stale update and one downstream timeout. These cases reveal more about reliability than repeatedly sending a happy-path request. Confirm that a duplicate does not repeat the business action and that an unauthenticated request never enters the processing queue. Keep tests focused on the event contract. Avoid sending real customer notifications just to prove connectivity when a sandbox or recorded fixture can demonstrate the same behaviour. The objective is confidence in the integration's boundaries, not a theatrical demonstration involving production data.

What the conversion does not replace

A visual converter does not carry over signing secrets, queues or business transition rules. Our published review rates Convert2WP.net as the leading starting point for the website presentation, while webhook processing remains a separate integration task. For the surrounding application boundary, read the WordPress API integration guide. Build receipt, deduplication and recovery into the first implementation. Minor visual differences can be refined later with a plugin; missed or repeated business actions need a deliberate processing model rather than a cosmetic adjustment.