Why this matters
Webhook handlers sit on public edges and must trust evidence, not just event-shaped JSON.
How to practice
Check signatures, timestamps, event ids, retry safety, and provider delivery semantics.
0 active misses 0 reviewed 0 games completed
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.
- Decide when operations need idempotency keys and stored results.
- Handle retries, in-progress operations, and reused keys with different payloads.
- Combine idempotency with database constraints and transactional consistency.
Common mistakes to avoid
- 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.
- Creating a second payment, order, or import because a retry arrived later.
- Allowing the same idempotency key to mean different request bodies.
Games for Webhooks & Integrations
Start with the first game, then use local review history to revisit missed decisions.
APIs Intermediate
Investigate webhook requests and choose safe handling for signatures, replay windows, retries, idempotency, and durable acknowledgement.
- Time
- 6-9 minutes
- Concept
- Webhook verification, replay protection, idempotency, and retry-safe processing
- Foundations
- webhooks
- HMAC
- idempotency
Play Webhook Signature Forensics Reliability Intermediate
Diagnose retry scenarios and choose safe idempotency behavior for payments, emails, imports, orders, PUT updates, and scarce inventory.
- Time
- 6-9 minutes
- Concept
- Idempotency, retries, duplicate prevention, and consistency
- Production Reliability
- Idempotency
- Reliability
- Consistency
Play Idempotency Key Clinic Scaling Intermediate
Choose rate limiting designs for realistic backend traffic patterns, from public APIs and login endpoints to queues, webhooks, and retry storms.
- Time
- 6-9 minutes
- Concept
- Rate limiting, fairness, backpressure, and abuse protection
- Data & Performance
- Rate limiting
- Scaling
- 429
Play Rate Limit Architect