---
title: "Discussion on \"Webhook Security: Verify Signatures, Stop Replays, Handle Retries\" | Hashnode"
description: "Discussion on \"Webhook Security: Verify Signatures, Stop Replays, Handle Retries\". How to accept webhooks safely: verify the signature on the raw body, reject replays with timestamps and event IDs, and survive retries, with tested Python code."
url: "https://hashnode.com/posts/webhook-security-verify-signatures-stop-replays-handle-retries-x05wj/6af4009606e33ac9878cf11a"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [Webhook Security: Verify Signatures, Stop Replays, Handle Retries](https://blog.zyvop.com/webhook-security-verify-signatures-stop-replays-handle-retries-x05wj?utm_source=hashnode&utm_medium=feed)

How to accept webhooks safely: verify the signature on the raw body, reject replays with timestamps and event IDs, and survive retries, with tested Python code.

7h ago · 28 min read · blog.zyvop.com  
Read the article

-   [#apidesign](https://hashnode.com/tag/apidesign)
-   [#fastapi](https://hashnode.com/tag/fastapi)
-   [#python](https://hashnode.com/tag/python)
-   [#security](https://hashnode.com/tag/security)
-   [#webhooks](https://hashnode.com/tag/webhooks)

## Written by

[ZyVOP](https://hashnode.com/@zyvop)

@zyvop · Delhi, India

  
[View profile](https://hashnode.com/@zyvop)

The Developer Publishing Hub

One platform to write, cross-post to Dev.to, Medium, WordPress, Hashnode, and Bluesky, and protect your SEO with canonical links. Zero paywalls and full content ownership.

## Responses 2

Markdown supported · ⌘↵ to post

[OneLifeVibe](https://hashnode.com/@onelifevibe)

[6h ago](https://hashnode.com/posts/webhook-security-verify-signatures-stop-replays-handle-retries-x05wj/6af4009606e33ac9878cf11a/comment/6af4085456905c21f27c79af)

The detail that stands out is verifying the signature against the raw bytes before any JSON parsing, since re-serialising a body that verified fine is exactly the kind of silent breakage that is hard to trace in production. The pairing of a short timestamp window with event-ID deduplication is also a neat division of labour: the window limits how long a captured request stays useful, while dedup makes a replay inside that window harmless. One question: with the five-minute window checked before the HMAC, how does the receiver handle a sender whose clock runs a little ahead — is the tolerance for future timestamps the same five minutes, or tighter?

[ZyVOP](https://hashnode.com/@zyvop)

[6h ago](https://hashnode.com/posts/webhook-security-verify-signatures-stop-replays-handle-retries-x05wj/6af4009606e33ac9878cf11a/comment/6af4085456905c21f27c79af#reply-6af40f1f56905c21f27c94f2)

In this implementation, the tolerance is the same five minutes in both directions. So a sender running slightly ahead is allowed, but anything beyond that is rejected. Keeping the server clock synced with NTP helps avoid these issues.