A webhook is an incoming request from outside your application. A JSON body that looks like a podcast event is not proof that it came from the provider.
Use the provider's documented signature procedure before trusting the event. The exact header names, signing input, algorithm, and time checks belong to that contract.
Keep the original bytes available
Many signature schemes depend on the raw request body. A JSON parser can change whitespace or key order when it reads and rewrites the content. Verifying a reconstructed object can therefore fail even when the original message was valid.
Configure your server framework to retain the body in the form required by the signature verifier. Set a reasonable body-size limit before accepting unbounded data. Keep signature verification separate from the business handler so both can be tested clearly.
Load the webhook secret from server-side secret storage. Do not confuse it with the workspace API key or assume that a bearer header alone replaces the documented signature check.
Reject carefully, process deliberately
An invalid signature should not trigger catalog changes, emails, or listener writes. Return the response required by your integration contract and record a safe reason code without copying the secret or full payload into logs.
For a valid event, validate the expected event shape before handing work to another component. Authenticity does not remove the need to check required fields and supported event types.
Test an unchanged signed fixture, a body with one altered byte, a missing header, and an oversized request. Also run the exact production framework path, because middleware order often matters more than the verifier's isolated unit test.