Q15 of 22 · Scenarios
How would you test a webhook integration?
ScenariosMidscenariowebhookapisecurityreliability
Short answer
Short answer: Clarify triggering events, retry policy, HMAC signing, and expected latency. Then cover delivery correctness, retry behavior on failure, signature validation, replay attack prevention, and idempotency for duplicate delivery.
Detail
Clarify first
- Which events trigger a webhook delivery, and what is the expected payload schema?
- Does the sender retry on failure — how many times, with what backoff?
- Is the payload signed (HMAC signature in a header) for integrity verification?
- What is the expected delivery latency SLA?
Functional
- Triggering event causes the correct payload to be delivered to the registered endpoint
- Payload structure and field values match the documented schema
- Delivery is confirmed via a 2xx response from the receiver endpoint
- Successful delivery is logged and observable (webhook dashboard or event log)
Negative / error handling
- Receiver endpoint returns 4xx or 5xx → sender retries according to the documented policy
- Receiver endpoint is completely down → retries exhaust; final failure logged; no infinite retry loop
- Payload with malformed data from the sender → receiver handles gracefully, returns appropriate status
- Delivery times out (receiver too slow) → sender treats as failure and retries
Edge & boundary
- Burst of events in a short window → all payloads delivered; no events silently dropped
- Events arriving out of order → receiver handles idempotently (order should not break state)
- Very large payload approaching the documented size limit
- Same event delivered twice (at-least-once guarantee) → idempotency handler on the receiver prevents duplicate processing
Security
- HMAC signature validation: reject payloads where the computed signature does not match the header value
- Replay attack prevention: payload contains a timestamp; receiver rejects payloads older than N seconds
- TLS verification: sender must present a valid certificate; self-signed or expired cert on the receiver should be rejected (or accepted, depending on config)
Reliability
- Test retry behavior by deliberately returning 500 from the receiver; confirm exponential backoff if documented
- Confirm idempotency handler: deliver the same event ID twice; verify it is processed only once
Close: automate signature validation, retry-on-failure (using a test endpoint that returns 500), schema assertions, and idempotency for duplicate delivery. Keep manual for observability verification — can the team see delivery status and failures in the dashboard or APM?
// WHAT INTERVIEWERS LOOK FOR
HMAC signature validation, replay attack prevention via timestamp, and idempotency for at-least-once delivery. These show understanding of webhook security and reliability beyond basic delivery testing.
// COMMON PITFALL
Only testing that the webhook fires on the triggering event. Missing retry behavior, signature validation, replay attacks, and idempotency for duplicate delivery — which are the failure modes that matter in production.