Skip to main content

Test sends and delivery debugging

Webhook endpoints should be tested before real customer activity depends on them. Use Switera test sends and delivery views to confirm that the receiver accepts, validates, and processes events correctly.

Start from the Event Catalog​

Switera webhook event catalog tab
Use the event catalog to choose only the events the receiver actually handles.

For each event family, decide:

  • why the receiver needs it
  • which database record or workflow it affects
  • whether duplicate events are safe
  • what should happen if processing fails
  • who owns the downstream workflow

Send a synthetic event​

Switera webhook test send tab
Test Send uses the same delivery pipeline as normal webhook traffic, so it is the quickest way to prove the receiver path.

Test send workflow:

  1. Create or choose an endpoint.
  2. Confirm the endpoint URL is HTTPS.
  3. Select the test event type.
  4. Send the test event.
  5. Check the receiver logs.
  6. Confirm signature verification.
  7. Confirm the receiver returns a success response.
  8. Review the Switera delivery record.

If no endpoint exists, add the endpoint before testing.

Review delivery history​

Switera webhook deliveries tab
Deliveries show whether events reached the endpoint and how the receiver responded.

Look for:

  • status
  • endpoint name
  • event type
  • attempt count
  • response status
  • response body or error summary
  • created and last-attempt timestamps

Use delivery history as the shared source of truth when product, backend, and support teams investigate a missed automation.

Debug failed deliveries​

Common causes:

SymptomLikely causeWhat to check
Connection timeoutReceiver unreachable or too slow.Public URL, firewall, receiver latency, health checks.
401 or 403Receiver rejected the request.Signature secret, auth middleware, route allowlist.
404Wrong endpoint path.Webhook URL, route prefix, deployment path.
500Receiver failed internally.Receiver logs, payload parsing, database errors.
Repeated duplicate side effectsReceiver is not idempotent.Event ID storage and duplicate handling.

Retry safely​

Retry after the receiver is fixed.

  1. Fix the receiver.
  2. Send one test event.
  3. Confirm success in the receiver and in Switera.
  4. Retry one failed delivery.
  5. Confirm the downstream action is correct.
  6. Retry the remaining affected deliveries.

Receiver checklist​

  • validates signatures
  • handles duplicate event IDs
  • returns quickly after accepting work
  • logs event type and delivery ID
  • avoids logging secrets
  • treats unknown event types as safe no-ops or explicit failures
  • has alerting for repeated failures

Related pages: