Understand webhook payload timestamps
Follow this guide to use the supplied timestamp in signature verification and replay policy. The guide then takes you through the correct route, the checks to complete before making changes, the workflow in order, and the evidence to review afterwards.
Where to goEnterprise POS → Settings → Signed webhooks
What you’ll accomplish
Use the supplied timestamp in signature verification and replay policy. This section documents endpoint safety checks, event selection, HMAC verification, delivery retries and dead-letter behaviour.
Follow these steps
- Go to Enterprise POS → Settings → Signed webhooks and open the workflow that matches “Understand webhook payload timestamps”. Confirm the page or record context before making a change.
- Create a public HTTPS endpoint that can receive POST JSON.
- Create a webhook with minimum event selection.
- Copy the full secret once.
- Check timestamp and signature before parsing/processing the event.
- Return a successful 2xx response promptly.
- Check downstream logs; the module retries transient failures through cron.
- Disable the webhook when it should stop receiving events.
Fields and options to review
- Guide focus: Use the supplied timestamp in signature verification and replay policy.
- Webhook name and HTTPS endpoint
- Selected event names
- One-time secret encrypted at rest
- Event ID, timestamp, signature and JSON payload
- Delivery status, attempt, next-attempt time, response code and excerpt
Rules the system enforces
- Endpoints must use HTTPS and must not resolve to localhost, .local, private, reserved or non-public addresses.
- All DNS results are validated and the first public IP is pinned for delivery.
- Redirects are disabled.
- Connect timeout is 5 seconds; total timeout is 10 seconds.
- Signature format is sha256=HMAC_SHA256(timestamp.payload, secret).
- Maximum attempts are 8; delay is 2^attempt × 30 seconds capped at 6 hours.
- After final failure the delivery becomes dead.
How to confirm it worked
- The specific outcome described by this guide is visible and remains tenant-scoped.
- A successful endpoint receives signed tenant event data.
- Transient failures are retried without duplicate queue creation for the same webhook/event.
- Disabled webhooks stop receiving new queued events.
Safety checks and troubleshooting
- Verify signatures using the raw request body.
- Reject stale/replayed timestamps under the receiver’s policy.
- Make receiver processing idempotent by event ID.
- Do not log secrets or full sensitive payloads.
Stay within the supported module flow
Use the supplied UI, host module lifecycle and documented endpoints. Do not bypass tenant filters, permissions, CSRF, idempotency, rate limits, audit evidence or transaction checks. A stored table or field does not imply that version 1.0.0 exposes a management screen for it.
Continue with related guidance
Was this guide useful?Your response is stored only in this browser.
