>_ Webhook Testing Checklist

Short answer

A Webhook Testing Checklist is a list of checks for incoming and outgoing webhook events. It helps verify that an event was generated, sent to the correct URL, received by the right system, verified securely, processed correctly, deduplicated, retried after failure, and logged clearly.

A webhook is a way for one system to notify another system about an event through an HTTP request. For example, a payment provider may send payment_succeeded, a shipping provider may send shipment_delivered, an email provider may send email_bounced, and GitHub may send an event when a pull request, issue, or repository event happens. GitHub's webhook documentation describes webhooks as event subscriptions that deliver data to a server when those events occur.

Webhook testing is not just checking whether an endpoint returned 200. It checks the full event flow:

1. event happened;
2. webhook was generated;
3. payload contains correct data;
4. webhook was sent to the correct URL;
5. receiving endpoint accepted the request;
6. signature/security was verified;
7. event was processed;
8. status or record was updated;
9. duplicate event did not create a duplicate;
10. failed webhook went into retry;
11. team can see delivery, logs, and error.

The main idea is: webhook testing checks whether event-based communication between systems is delivered, verified, processed, retried, and logged correctly.

Webhook Testing vs API Testing

API Testing checks an endpoint as a contract.

For example:

• endpoint accepts a request;
• status code is correct;
• request validation works;
• response schema is correct;
• authentication works;
• invalid request returns the expected error.

Webhook Testing checks event-driven behavior between systems.

For example:

• correct event type was sent;
• payload contains correct fields;
• event ID is unique;
• webhook reached the receiving endpoint;
• signature was verified;
• duplicate webhook did not create a duplicate order;
• failed delivery went into retry;
• out-of-order event was handled safely;
• logs show what happened.

In simple terms:

API Testing: does the endpoint work correctly? Webhook Testing: was the event delivered, verified, processed, and handled without harmful side effects?

Webhook Testing vs API Integration Testing

API Integration Testing is broader. It checks the whole exchange between systems:

• API requests;
• authentication;
• data mapping;
• retries;
• webhooks;
• status sync;
• reconciliation;
• logs;
• monitoring;
• data consistency.

Webhook Testing is narrower and more specific. It focuses on webhook event delivery and event processing:

• event trigger;
• webhook payload;
• webhook URL;
• signature verification;
• receiving endpoint;
• status code response;
• duplicate handling;
• retry;
• delivery logs;
• manual resend;
• event ordering.

For example:

API Integration Testing: checkout created a payment intent, payment provider returned a response, webhook updated the order, and ERP received the order.

Webhook Testing: specifically checks that the payment_succeeded webhook was delivered, signature was valid, duplicate webhook did not create a second order, and failed delivery retry works.

Incoming Webhooks vs Outgoing Webhooks

Webhook testing can cover two directions: incoming webhook testing and outgoing webhook testing.

Incoming webhooks are events your product receives from another system.

For example:

• payment provider sends payment_succeeded;
• email provider sends email_bounced;
• shipping provider sends shipment_delivered;
• GitHub sends pull_request.opened;
• external CRM sends a status update;
• identity provider sends user deactivation event.

For incoming webhooks, check:

• endpoint is available;
• URL is correct;
• signature is verified;
• payload is recognized;
• event is processed;
• status is updated;
• duplicate event does not create a duplicate;
• failed processing is logged.

Outgoing webhooks are events your product sends to a customer, partner, or external system.

For example:

• your SaaS sends subscription_created to a customer;
• marketplace sends seller webhook order_created;
• booking platform sends partner webhook reservation_cancelled;
• internal system sends CRM webhook lead_created;
• product sends invoice_paid to accounting system.

For outgoing webhooks, check:

• event is generated;
• payload is correct;
• destination URL is correct;
• signing secret is used;
• delivery status is stored;
• failed delivery is retried;
• customer can see delivery history;
• manual resend works;
• rate limits and retry policy do not break the receiving system.

When to use a Webhook Testing Checklist

Use this checklist whenever the product receives or sends webhook events.

For example:

• payment webhook is added;
• Stripe, PayPal, or another payment provider changes;
• subscription webhook is added;
• email provider webhook changes;
• CRM or lead webhook is added;
• shipping provider changes;
• GitHub/GitLab webhook is added;
• SaaS product starts sending outgoing webhooks to customers;
• webhook payload changes;
• event type changes;
• signature verification changes;
• retry behavior changes;
• callback URL changes;
• manual resend is added;
• delivery history is added;
• there was a production incident: webhook did not arrive, arrived twice, arrived out of order, failed signature verification, or did not update status.

For a small webhook configuration change, a short API smoke test may be enough. For payment, order, subscription, billing, shipping, CRM, email, or customer-facing outgoing webhooks, it is better to go through the full Webhook Testing Checklist.

Short Webhook Testing Checklist

If you need a minimal webhook smoke test, check that:

• webhook event trigger works;
• expected event type is sent;
• webhook URL is correct;
• sandbox and production URLs are not mixed up;
• receiving endpoint is available;
• payload contains correct fields;
• event ID is present;
• timestamp is present;
• signature verification works;
• invalid signature is rejected;
• receiver returns expected success status;
• event is processed;
• related record is updated;
• duplicate event does not create duplicate record;
• retry works after temporary failure;
• timeout is handled;
• failed delivery is visible in delivery history or logs;
• manual resend works, if supported;
• out-of-order event does not break final state;
• logs contain event ID, delivery ID, status, and error;
• sensitive data and secrets are not written to logs;
• production webhook smoke has passed after release.

This is not a full API Integration Testing Checklist. It is a quick check that shows whether the webhook event flow works at a basic level.

Webhook Testing Checklist

1. Define webhook scope

Before testing, understand which webhook events are in scope.

Check that:

• incoming webhook or outgoing webhook is being tested;
• participating systems are known;
• sending system is known;
• receiving system is known;
• event types in scope are listed;
• event types outside scope are listed;
• records that should be created are known;
• records that should be updated are known;
• statuses that should change are known;
• business workflows depending on the webhook are known;
• environments are known;
• required security checks are known;
• webhook integration owner is known;
• pass / fail decision owner is known.

The main question is: which event should move from System A to System B, and what result should it cause?

2. Identify event types

Webhook testing starts with event types.

Check that:

• event type list is known;
• each event type is documented;
• event type names are stable;
• event type matches business action;
• deprecated event types are marked;
• new event types are supported by receiver;
• receiver ignores unknown event types safely;
• receiver does not crash on unsupported event;
• event subscription includes only needed events;
• unnecessary events are not sent.

Examples of event types:

• payment_succeeded;
• payment_failed;
• invoice_paid;
• subscription_cancelled;
• order_created;
• shipment_delivered;
• email_bounced;
• lead_created;
• pull_request.opened.

Security and reliability question: does the receiver receive only the events it is expected to process?

For deeper checks around tokens, secrets, CORS, abuse protection, and sensitive data, use the REST API Security Testing Checklist.

3. Prepare sender and receiver environments

Webhook bugs often come from incorrect environment configuration.

Check that:

• sender environment is ready;
• receiver environment is ready;
• sandbox sender points to sandbox receiver;
• production sender points to production receiver;
• staging URL is not used in production;
• production URL is not used in sandbox unless intentional;
• callback/webhook URL is correct;
• test mode is enabled where needed;
• feature flags are configured;
• DNS and TLS work;
• firewall or allowlist does not block webhook;
• receiving endpoint is publicly reachable if provider requires public URL;
• localhost is not used where provider does not support it.

Classic mistake: production webhook sends data to staging, or staging webhook suddenly sends events to production.

4. Check webhook URL configuration

Webhook URL is one of the first things to verify.

Check that:

• URL is correct;
• https:// scheme is used if required;
• path is correct;
• environment is correct;
• there is no localhost URL;
• there is no old domain;
• there is no typo in path;
• trailing slash behavior is correct if system is sensitive to it;
• receiver route exists;
• URL is reachable by sender system;
• URL does not return 404;
• URL does not redirect unexpectedly;
• URL does not expose secrets in query string.

Security question: is the webhook sent to the correct endpoint, and does the URL avoid sensitive data?

5. Check event trigger

Webhook should be sent after the correct event.

Check that:

• expected action triggers webhook;
• event is generated only after real event;
• failed action does not send success webhook;
• canceled action sends correct canceled event, if expected;
• pending state sends correct event, if expected;
• event is not sent too early;
• event is not sent too late for business workflow;
• event is not sent multiple times without reason;
• event is generated for correct account/workspace;
• event trigger is visible in sender logs.

Example: payment_succeeded should be sent after confirmed successful payment, not after the initial checkout click.

6. Check payload structure

Payload should be understandable and stable.

Check that:

• payload is valid JSON if JSON is expected;
• top-level structure is correct;
• event type is present;
• event ID is present;
• timestamp is present;
• data object is present;
• resource ID is present;
• account/customer ID is present if needed;
• nested objects are structured correctly;
• arrays are formatted correctly;
• raw internal model is not leaked accidentally;
• no unexpected breaking schema change appears;
• receiver parses payload correctly.

Webhook payload is a contract between sender and receiver. If structure changes without versioning, the receiving system may silently break.

7. Check required fields

Receiver should receive all fields needed to process the event.

Check that:

• required event fields are present;
• required resource fields are present;
• required IDs are present;
• amount is present if this is a payment event;
• currency is present if this is a payment event;
• status is present if this is a status event;
• customer/order/reference ID is present;
• metadata is present if needed;
• missing optional fields are handled;
• missing required field is rejected or logged;
• incomplete payload does not create broken record.

The main question is: can the receiver process the event without guessing?

8. Check event ID and timestamp

Event ID is needed for logs, debugging, deduplication, and idempotency.

Check that:

• event ID is present;
• event ID is unique;
• event ID is stable across retries;
• delivery ID is present if sender provides it;
• timestamp is present;
• timestamp format is correct;
• timezone is clear;
• event creation time is distinguishable from delivery time;
• event ID is stored after processing;
• duplicate event is detected by event ID;
• logs are searchable by event ID.

Without event ID, webhook debugging turns into “it got lost somewhere.”

9. Check signature verification

Webhook receiver should know that the request came from a trusted sender.

Check that:

• signature header is present;
• signing secret is configured;
• receiver verifies signature;
• invalid signature is rejected;
• missing signature is rejected if signature is required;
• wrong secret is rejected;
• old secret is rejected after rotation if expected;
• raw body is preserved if provider requires it;
• proxy/load balancer does not modify body before verification;
• timestamp tolerance is checked if provider supports replay protection;
• verification failure is logged safely.

Stripe webhook documentation recommends verifying signatures with the event payload, the Stripe-Signature header, and the endpoint secret. It also notes that the raw request body must remain unmodified for signature verification to succeed.

10. Check authentication and secret handling

Some webhook systems use shared secret, HMAC signature, bearer token, API key, mTLS, or allowlist.

Check that:

• secret is stored securely;
• secret is not hardcoded;
• secret is not logged;
• secret is not exposed in frontend;
• secret is different for sandbox and production;
• secret rotation is possible;
• old secret is revoked if needed;
• bearer token is validated if used;
• API key is validated if used;
• IP allowlist works if used;
• unauthorized webhook request is rejected;
• failure does not expose secret.

Security question: can a third party forge the webhook or learn the signing secret?

11. Check correct status code response

Sender usually decides success/failure delivery based on HTTP response.

Check that:

• successful processing returns expected 2xx;
• invalid signature returns expected non-2xx;
• malformed payload returns expected error;
• temporary failure returns retryable status if appropriate;
• permanent failure is handled according to sender rules;
• receiver does not return 200 before safe minimal validation if that would lose the event;
• receiver does not return 500 for already processed duplicate if duplicate should be acknowledged;
• response body does not expose internals;
• response time is within provider limit.

GitHub records webhook delivery as failed when the server returns a 4xx or 5xx response and recommends configuring the server to return a 2xx status for successful handling.

12. Check successful processing

Webhook delivery is useful only if the receiver actually processes the event.

Check that:

• event is received;
• event is parsed;
• signature is verified;
• related record is found;
• target record is created or updated;
• status is updated correctly;
• side effect is executed if expected;
• event is marked as processed;
• processing result is stored;
• success is visible in logs/admin;
• no duplicate side effect happens;
• final state matches expected business rule.

Example: payment_succeeded should update order payment status, not just return 200.

13. Check duplicate webhook handling

Webhook providers may send the same event more than once. Receiver must be safe.

Check that:

• same event is delivered twice;
• duplicate is detected by event ID;
• duplicate does not create duplicate order;
• duplicate does not create duplicate payment;
• duplicate does not send duplicate email;
• duplicate does not start fulfillment twice;
• duplicate returns successful response if already processed;
• duplicate processing is logged clearly;
• processed event store works;
• duplicate across retries is handled;
• duplicate after manual resend is handled.

Stripe recommends checking whether an event is already processing or processed when handling undelivered events, which helps prevent duplicate processing during automatic retries or manual recovery.

14. Check idempotency

Idempotency means that processing the same event multiple times does not create multiple side effects.

Check that:

• event processing is idempotent;
• event ID is stored before or during processing according to safe design;
• already processed event is skipped safely;
• in-progress event is handled;
• concurrent duplicate delivery is safe;
• database constraints prevent duplicate side effects;
• idempotency works after retry;
• idempotency works after manual resend;
• idempotency works after server restart;
• idempotency does not hide a real new event.

Security/reliability question: what happens if the same event arrives twice or at the same time?

15. Check retry behavior

If receiver is temporarily unavailable, sender should retry or the team should have a recovery path.

Check that:

• failed delivery triggers retry according to sender rules;
• retry delay is acceptable;
• retry count or duration is known;
• retry uses same event ID;
• retry uses same payload or documented updated payload;
• retry does not create duplicate side effect;
• receiver can process retried event;
• retry stops after successful processing;
• retry failures are visible;
• retries do not overload receiver.

Stripe states that in live mode it attempts to deliver events for up to three days with exponential backoff; sandbox events are retried fewer times over a shorter period.

16. Check timeout behavior

Webhook sender may mark delivery as failed if receiver takes too long to respond.

Check that:

• receiver responds within expected timeout;
• long processing is moved to background job if needed;
• timeout is logged;
• timeout triggers retry if expected;
• timed-out event is not marked processed unless safe;
• later retry is handled idempotently;
• user-facing status is not falsely marked complete;
• operations can see timeout failure;
• slow dependency does not block webhook response too long;
• repeated timeouts alert the team.

Webhook handler should be fast and reliable. Long business processing is often safer in a queue or background job.

17. Check failed delivery

Failed delivery should be visible and recoverable.

Check that:

• failed delivery is recorded;
• failure reason is visible;
• response status is stored;
• response body is stored safely, if available;
• delivery timestamp is stored;
• event ID is visible;
• receiver logs show failure;
• sender delivery history shows failure;
• alert is triggered if critical;
• event can be retried or manually resent;
• failure does not silently lose business-critical event.

GitHub lets webhook owners view details for recent webhook deliveries, including request headers, payload, delivery time, and the response received from the server; this kind of delivery history is useful for verifying and troubleshooting webhook behavior.

18. Check manual resend

Manual resend is needed for recovery after failure.

Check that:

• manual resend is available if product/provider supports it;
• resend sends the same event;
• event ID remains stable or mapping is clear;
• duplicate handling works on resend;
• already processed event is not processed twice;
• failed event can be recovered;
• resend action is logged;
• resend permission is restricted;
• support can trigger resend if appropriate;
• resend result is visible;
• resend does not bypass signature verification.

GitHub supports manual redelivery of webhook deliveries from the past three days, while failed deliveries are not automatically redelivered by GitHub.

19. Check out-of-order events

Webhook events may arrive in a different order than the events happened.

Check that:

• older event arriving after newer event does not overwrite correct state;
• timestamp is used if ordering matters;
• status transition rules protect final state;
• payment_failed after payment_succeeded is handled safely;
• shipment_delivered before shipment_in_transit is handled safely;
• subscription update and cancellation ordering is handled;
• receiver can fetch latest resource state if needed;
• event ordering assumptions are documented;
• out-of-order event is logged.

GitHub notes that webhook deliveries may arrive in a different order than the events occurred and recommends using timestamps in the payload when event order matters.

20. Check delayed events

Webhook delivery may be delayed.

Check that:

• delayed event is still processed;
• delayed event is not treated as invalid only because of age unless security policy requires it;
• timestamp is checked for replay window where required;
• status is not overwritten incorrectly by old delayed event;
• user-facing state handles pending period;
• delayed event is visible in logs;
• retry delay is acceptable;
• operations can see delayed state;
• system can reconcile if delay exceeds expectation.

Delayed event should not break final state or create confusion for user/support.

21. Check event versioning

Webhook payloads can change. Receiver should be ready for versioning.

Check that:

• event version is present if supported;
• receiver handles current version;
• receiver rejects unsupported version safely;
• old version is still supported if promised;
• new optional fields do not break receiver;
• missing optional fields are handled;
• enum expansion is handled;
• deprecated fields are handled;
• payload changes are documented;
• test events cover version changes.

Webhook versioning is especially important for public outgoing webhooks, partner APIs, and long-lived integrations.

22. Check sandbox vs production URLs

Environment mismatch is one of the most common webhook problems.

Check that:

• sandbox webhook points to sandbox receiver;
• production webhook points to production receiver;
• test events do not hit production business data;
• production events do not hit staging;
• sandbox signing secret is different from production;
• production signing secret is configured;
• callback URLs match environment;
• webhook delivery history shows correct destination;
• no old staging URL remains;
• no localhost URL appears in provider configuration;
• production smoke uses safe test event.

Webhook config should be reviewed before every release that changes domain, provider, environment variables, or deployment setup.

23. Check logs and delivery history

Webhook failures are painful without logs.

Check that logs contain:

• event ID;
• delivery ID if available;
• event type;
• webhook URL;
• timestamp;
• signature verification result;
• response status;
• processing status;
• related internal record ID;
• external resource ID;
• retry count;
• error reason;
• environment;
• correlation/request ID.

Check that logs do not contain:

• webhook secret;
• full tokens;
• API keys;
• full payment details;
• unnecessary sensitive personal data;
• raw payload with secrets unless securely controlled.

The main question is: can the team understand exactly where the webhook failed: trigger, delivery, verification, processing, or downstream update?

24. Check monitoring and alerts

Critical webhook flows should be monitored.

Check that:

• webhook success rate is monitored;
• webhook failure rate is monitored;
• retry count is monitored;
• timeout rate is monitored;
• signature failure rate is monitored;
• duplicate rate is monitored if possible;
• queue backlog is monitored;
• delayed event processing is monitored;
• no-event condition is monitored if expected events stop arriving;
• alert threshold is configured;
• alert goes to the correct team;
• dashboard exists for critical integrations.

Without monitoring, webhook flow can be broken for hours or days before a customer reports that payment, order, or status did not update.

25. Check security and sensitive data

Webhook payloads often contain sensitive business data.

Check that:

• signature verification is enabled;
• invalid signature is rejected;
• webhook endpoint does not accept anonymous spoofed events;
• secret is stored securely;
• secret rotation is possible;
• webhook payload does not contain unnecessary sensitive data;
• logs do not expose secrets or full tokens;
• payload contains only required data;
• private objects remain protected after webhook processing;
• event cannot update another tenant’s record;
• replay attack protection is considered;
• receiver validates event source and resource ownership.

Security question: can an attacker spoof a webhook, replay an old event, or make the receiver update the wrong resource?

26. Check receiver endpoint hardening

Webhook receiver is a public-facing endpoint in many architectures.

Check that:

• only expected HTTP method is allowed;
• unexpected method is rejected;
• content type is validated;
• payload size is limited;
• malformed JSON is handled;
• request body is preserved for signature verification if needed;
• request timeout is configured;
• rate limits or abuse protection are considered;
• no stack traces appear in response;
• no sensitive debug response appears;
• endpoint is not used for unrelated public access;
• endpoint can handle provider retry bursts.

Webhook endpoint should be forgiving enough for reliable delivery, but not open to unsafe requests.

27. Check business state update

Webhook usually should change business state.

Check that:

• payment status is updated;
• order status is updated;
• subscription status is updated;
• shipment status is updated;
• email status is updated;
• lead status is updated;
• ticket status is updated;
• booking status is updated;
• related record is found correctly;
• unknown record is handled;
• already final state is not overwritten incorrectly;
• update is visible in UI/admin/API;
• update triggers correct next step if expected.

Webhook testing does not end at delivery. Final business state must be checked.

28. Check downstream side effects

Webhook processing can trigger side effects.

Check that:

• confirmation email is sent once;
• order fulfillment is started once;
• subscription access is activated once;
• invoice is marked paid once;
• CRM status is updated once;
• support ticket is updated once;
• notification is sent once;
• analytics event is sent once;
• no side effect happens on failed signature;
• no side effect happens on invalid payload;
• no duplicate side effect happens on retry.

Dangerous case: duplicate webhook does not create duplicate record, but it still sends duplicate email or starts fulfillment twice.

29. Check queue and async processing

Webhook receiver often puts events into a queue.

Check that:

• webhook request creates job;
• job payload is correct;
• job preserves event ID;
• job is processed;
• job failure is logged;
• failed job is retried;
• dead-letter queue exists if used;
• queue backlog is visible;
• duplicate jobs are safe;
• job status is connected to delivery/event;
• manual replay is possible if needed.

If receiver quickly returns 2xx and processes the event asynchronously, separately verify that the job actually completed.

30. Check reconciliation

Webhook can be lost, delayed, or fail. Reconciliation catches mismatches.

Check that:

• source system event exists;
• receiver system state matches event;
• missing events are detectable;
• failed events are listed;
• duplicate events are detectable;
• payment/order/subscription statuses can be compared;
• manual reconciliation is possible;
• periodic reconciliation exists if business-critical;
• support can compare by event ID, resource ID, customer ID, or timestamp;
• reconciliation result is visible to operations.

Reconciliation is especially important for payments, invoices, subscriptions, orders, fulfillment, and finance workflows.

31. Check outgoing webhook delivery

If your product sends webhooks to customers or partners, check outgoing flow.

Check that:

• event is generated;
• destination URL is selected correctly;
• payload is correct;
• signature is added;
• delivery is attempted;
• response status is stored;
• success is recorded;
• failure is recorded;
• retry is scheduled;
• customer can view delivery if product supports it;
• customer can rotate secret if supported;
• customer can disable webhook;
• customer can choose event types.

Outgoing webhook is part of developer experience. The customer should understand what was sent and what their server returned.

32. Check outgoing webhook customer configuration

For customer-facing webhooks, check that:

• customer can add webhook URL;
• invalid URL is rejected;
• HTTP URL is rejected if HTTPS is required;
• localhost is rejected if not allowed;
• secret is generated securely;
• event subscriptions are configurable;
• test event can be sent;
• disabled webhook does not receive events;
• deleted webhook does not receive events;
• URL update works;
• secret rotation works;
• permission is required to manage webhooks.

Customer should not be able to accidentally configure a webhook that silently fails.

33. Check webhook testing tools and test events

Webhook systems often support test events.

Check that:

• test event can be sent;
• test event is marked as test;
• test event does not create production side effect;
• test payload is realistic;
• test signature is valid;
• test delivery is visible in logs;
• test event does not accidentally trigger fulfillment/payment/email;
• test event can be repeated safely;
• local development forwarding works if supported;
• documentation explains test event behavior.

Test webhook helps quickly verify setup without a real business event.

34. Run production webhook smoke after release

After webhook-related release, run a short production smoke test.

Check that:

• production webhook URL is correct;
• production signing secret is correct;
• safe event triggers webhook;
• delivery appears in sender history;
• receiver logs event;
• signature is verified;
• event is processed;
• related safe record is updated;
• duplicate event is safe if tested;
• retry/failure behavior is visible if safely testable;
• no staging URL is used;
• no test payload is exposed to real customers;
• monitoring is stable;
• no increase in webhook failures appears.

Production webhook smoke should be short, safe, and agreed in advance.

35. Document webhook testing result

Webhook bugs need good evidence.

Document:

• event type;
• event ID;
• delivery ID;
• sender system;
• receiver system;
• environment;
• webhook URL;
• timestamp;
• payload sample or safe reference;
• signature verification result;
• response status;
• processing result;
• related record ID;
• retry count;
• logs/correlation ID;
• issue found;
• pass/fail decision.

Bug report “webhook did not arrive” is almost useless without event ID, delivery timestamp, URL, response status, and receiver logs.

Common mistakes

1. Checking only that endpoint returned 200

A 200 response does not prove that the event was processed, state was updated, or side effects happened correctly.

2. Not verifying signatures

Without signature verification, receiver may process spoofed webhook requests.

3. Not handling duplicate events

Webhook delivery is often at-least-once. Duplicate events should not create duplicate orders, payments, emails, or fulfillment.

4. Not storing event ID

Without event ID, deduplication, logs, replay, troubleshooting, and reconciliation become much harder.

5. Ignoring retry behavior

Temporary failures happen. Receiver and sender should handle retry without duplicate side effects.

6. Assuming events arrive in order

Events can be delayed or delivered out of order. Final state should be protected by timestamps, status rules, or fetching latest source state.

7. Mixing sandbox and production URLs

Wrong webhook URL can send real events to staging or test events to production.

8. Not checking logs and delivery history

Webhook issues become “lost somewhere” if sender delivery logs and receiver processing logs are missing.

9. Returning success before safe validation

Returning 2xx before signature verification or safe event storage can make failures invisible.

10. Not testing manual resend or recovery

If a business-critical webhook fails, the team needs a safe way to retry or reconcile.

FAQ

What is a Webhook Testing Checklist?

A Webhook Testing Checklist is a list of checks for verifying webhook events.

It helps confirm that event-based communication between systems is triggered, delivered, verified, processed, retried, deduplicated, and logged correctly.

What is webhook testing?

Webhook testing checks whether a webhook event is sent by the source system, delivered to the receiver, verified securely, processed correctly, and reflected in the target system.

It also checks retries, duplicates, out-of-order events, failed deliveries, logs, and manual resend.

How is webhook testing different from API testing?

API testing checks an endpoint as a contract: status code, request validation, response schema, authentication, and errors.

Webhook testing checks event-driven communication: event type, payload, event ID, delivery, signature, processing, duplicate handling, retry, logs, and final business state.

How is webhook testing different from API integration testing?

API integration testing checks the whole exchange between systems, including API requests, mapping, retries, webhooks, reconciliation, and status sync.

Webhook testing focuses specifically on webhook delivery and processing.

What should be checked in webhook testing?

At minimum, check:

• event trigger;
• event type;
• webhook URL;
• payload;
• required fields;
• event ID;
• timestamp;
• signature verification;
• receiving endpoint response;
• successful processing;
• duplicate handling;
• retries;
• failed delivery;
• manual resend;
• out-of-order events;
• logs;
• monitoring;
• production smoke.

How do you test webhook signature verification?

Send a valid signed webhook and confirm it is accepted.

Then send a webhook with missing, invalid, or wrong signature and confirm it is rejected without side effects.

Also check that the raw request body is not modified before verification if the provider requires raw body.

How do you test duplicate webhooks?

Deliver the same event twice using the same event ID.

Expected result: receiver should process it once or safely ignore the second delivery. It should not create duplicate order, payment, email, fulfillment, or status update.

How do you test webhook retry behavior?

Make the receiver temporarily return an error or timeout.

Expected result: sender marks delivery as failed and retries according to policy. When receiver recovers, event is processed once and no duplicate side effect appears.

How do you test out-of-order webhook events?

Send events in a different order than the real business timeline.

Expected result: receiver should not overwrite a newer final state with an older event. It should use timestamps, state transition rules, or fetch latest source state if needed.

What is webhook idempotency?

Webhook idempotency means processing the same event multiple times produces the same final result as processing it once.

It prevents duplicate records, duplicate payments, duplicate emails, and duplicate fulfillment when webhook delivery is repeated.

What logs are needed for webhook testing?

Useful webhook logs include:

• event ID;
• delivery ID;
• event type;
• webhook URL;
• timestamp;
• signature verification result;
• response status;
• processing status;
• related internal record ID;
• external resource ID;
• retry count;
• error reason;
• correlation ID.

How do you know webhook testing passed?

Webhook testing can be considered passed when:

• expected event is triggered;
• payload is correct;
• webhook is delivered to the right URL;
• signature verification works;
• receiver returns correct status;
• event is processed correctly;
• duplicate events are safe;
• retry works for temporary failure;
• out-of-order events do not break state;
• delivery history and logs are useful;
• sensitive data and secrets are protected;
• production webhook smoke has passed.