Concept explanation
Webhook endpoints are tiny doors into important backend state. This game treats each delivery like a forensic case: prove the evidence is authentic, fresh, unique enough, and safely accepted before it changes anything valuable.
All games
Webhook Signature Forensics
Investigate webhook requests and choose safe handling for signatures, replay windows, retries, idempotency, and durable acknowledgement.
- Concept
- Webhook verification, replay protection, idempotency, and retry-safe processing
- Difficulty
- Intermediate
- Play time
- 6-9 minutes
- Path
- Foundations
practice/webhook-signature-forensics Webhook forensics score Play, get feedback, save local progress, and optionally submit a leaderboard score.
Playable game area
Use the controls below. Feedback appears immediately, and final scores are stored locally.
Leaderboard
Top 10 submitted scores. No account required.
Loading leaderboard...
Finish the game to load your latest local score.
Learning objectives
- Verify webhook authenticity using raw request bodies and signatures.
- Recognize replay attacks, duplicate deliveries, and unsafe side effect ordering.
- Design webhook handlers that acknowledge only after durable acceptance.
How to play
- Inspect the webhook evidence: body handling, signature, timestamp, event id, and side effects.
- Choose the handler behavior that keeps production state trustworthy.
- Read each explanation to separate authenticity, freshness, and retry safety.
Scoring
- Correct investigations add points and streak bonuses.
- Risky decisions reveal how webhook handlers fail in production.
- Final score is saved locally and can be submitted to the leaderboard.
Backend concept notes
Webhook delivery is at-least-once in many systems, so valid events can arrive more than once. The handler must verify the sender and make side effects idempotent.
A safe webhook path verifies the raw signed payload, enforces timestamp tolerance, stores dedupe state, persists accepted work durably, and returns 2xx only after the event is safe to process internally.
Common mistakes
- Verifying a re-serialized JSON body instead of the raw body bytes.
- Treating a valid signature as proof that the event is fresh or unique.
- Sending emails or charging accounts before durable dedupe state exists.
- Returning 500 for work that has already been durably accepted.
FAQ
Short answers for how this game fits backend interview and study practice.
Why do webhooks need idempotency if they are signed?
A signature proves who sent the event. It does not prove this is the first delivery. Providers retry signed events after timeouts and network failures.
Should webhook handlers do all business work synchronously?
Usually no. A common pattern is verify, persist, enqueue internal work, then acknowledge with 2xx so provider retries do not amplify downstream delays.