2xx response.
Delivery headers
Every delivery attempt carries these headers:
Headers describe the delivery attempt; the body describes the event. On a replay,
Sphere-Timestamp and Sphere-Signature are freshly generated — so the same verification code path handles originals and replays — while the body remains byte-for-byte identical to the original.
How the signature is computed
The signature is an HMAC-SHA256 digest, hex-encoded:secret— the endpoint’s signing secret (whsec_...), returned once when you created the endpoint.timestamp— the value of theSphere-Timestampheader.rawBody— the raw HTTP request body bytes, exactly as transmitted.
Sphere-Signature using a constant-time comparison.
Guard against replay attacks
To prevent captured deliveries from being re-sent by a third party, reject deliveries whoseSphere-Timestamp is more than 5 minutes old. Manual replays get a fresh timestamp and signature, so legitimate replays always pass this check.
Reference implementations
Each snippet takes the raw body bytes, the two headers, and your endpoint secret, and returns whether the delivery is authentic.When verification fails
Respond with a non-2xx status code (for example 401) and do not process the payload. The delivery is recorded as failed on SpherePay’s side, giving you an audit trail in the Events API.
If you registered the same receiver URL under multiple SpherePay applications, each application’s endpoint has its own secret. Use the
applicationId in the payload to select the correct secret — see Event payloads. If you cannot parse the body before verifying, try each of your known secrets.