Pepvote Support Center
Webhooks

Delivery and retries

How Pepvote delivers webhook events and handles failures.

Success criteria

A delivery is successful when your endpoint responds with any 2xx status code within 15 seconds.

Pepvote does not follow redirects. Your endpoint must respond at the configured URL.

Retry schedule

If your endpoint returns a non-2xx status code, times out, or is unreachable, Pepvote retries with exponential backoff:

AttemptDelay after previous attempt
1Immediate
21 minute
35 minutes
430 minutes
52 hours
68 hours

After 6 failed attempts, the delivery is marked as permanently failed.

Auto-disable

If an endpoint accumulates 15 consecutive failures across any events, it is automatically disabled. You will see a message on the endpoint card explaining why.

To resume deliveries, fix the issue on your receiver and click Enable on the endpoint card. Re-enabling resets the failure counter.

Ordering

Events are delivered in approximate chronological order, but strict ordering is not guaranteed. Your receiver should handle out-of-order arrivals by checking the createdAt timestamp in the payload.

Use the id field in the payload as an idempotency key to avoid processing the same event twice. Retry attempts reuse the same event ID.

Delivery log

Every delivery attempt is recorded and visible in the Webhook deliveries section of your dashboard. Each entry shows:

  • Event ID and event type
  • HTTP status code (or error message for network failures)
  • Attempt number
  • Timestamp
  • Full request payload (click to expand)
  • Response body (first 4 KB)

Filtering deliveries

Use the toolbar filters to narrow the delivery log:

  • Status: All, Succeeded, Failed, or Pending
  • HTTP response: All, 2xx, 4xx, 5xx, or No response
  • Event type: Filter by specific event types, grouped by resource
  • Search: Find deliveries by event ID

Retention

Delivery records are kept for 30 days and then removed automatically.

Event-level override behavior

When a voting event has its own webhook endpoints, those endpoints replace account-level endpoints for that event. Account-level endpoints do not fire for events that have their own endpoints configured.

If no event-level endpoints exist for a voting event, the account-level endpoints apply as normal.

Was this helpful?

Last updated August 25, 2026

On this page