## TL;DR
Webhook retries have no ordering guarantee. Store a per-recipient sequence number or timestamp, ignore stale events, and drive the drip from your own state machine instead of raw webhook order.

```text
webhook handler processed retries out of order and agent sent the drip sequence backwards
```

## Use this when
- A drip campaign fired steps out of order after webhook retries.
- Logs show an older event processed after a newer one.
- Retries from the provider arrive minutes late and trigger stale actions.

## Not for this skill when
- Duplicate webhook deliveries, which need idempotency keys only.
- Missing webhooks, which need a reconciliation job.
- Provider-side ordering guarantees, which webhooks do not offer.

## Steps
1. Confirm the ordering failure in logs: match event timestamps against processing order. Verify: you have examples of older events processed later.
2. Add a sequence guard: store the last processed event time per recipient and skip older events. Verify: a replayed old event is ignored in a test.
3. Make every send idempotent with a key derived from recipient plus step. Verify: processing the same event twice sends once.
4. Move the drip logic into your own state machine driven by the latest known state, not by event arrival order. Verify: the state machine produces the right next step regardless of order.
5. Respond 200 fast and process asynchronously so retries do not stack up. Verify: handler latency stays under a second under retry load.

## Variant phrasings
### webhook retries out of order
Common phrasing of the problem.
### webhook idempotency ordering drip campaign
The drip-angle search.
### handle out of order webhooks
The pattern-angle search.

Compatibility: Any webhook provider (Stripe, HubSpot, and similar); at-least-once delivery without ordering is universal.

## Why it happens
Providers retry failed webhooks on their own schedule, so a retry of step 1 can arrive after step 2 already processed. A handler that acts on arrival order instead of event arrival time will happily run the sequence backwards.

## Edge cases / pitfalls
- Clock skew between systems makes timestamp guards fuzzy; prefer sequence numbers when the provider offers them.
- Ignoring stale events needs care during legitimate replays; distinguish replays from retries.
- Async processing needs its own ordering; a queue without ordering just moves the bug.
- Dead-letter the events you skip so an audit can explain the gap.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Pf9-p1odNwcRMeH9FwO0og