Skip to main content
Start in the delivery log at Workspace Settings > Integrations > Webhooks > Delivery log. Click Show details on the failing row — the response body and error message usually identify the cause on their own.

Common symptoms

Diagnosing in detail

In order of likelihood:
  1. You are hashing the wrong bytes. JSON middleware parses and discards the raw body. Hash the raw bytes exactly as received, before anything parses them.
  2. Your secret is stale. Rotating invalidates the previous secret immediately, with no overlap. Copy the current value from the settings page.
  3. You are hashing the Timestamp header too. It is not part of the signature.
  4. Encoding mismatch. The signature is lowercase hex, not base64.
No status code means Edplay never got a response. Check that:
  • the URL is publicly reachable, not localhost or a private IP range;
  • the TLS certificate is valid, unexpired, and publicly trusted, since self-signed certificates fail;
  • your firewall is not blocking Edplay’s servers;
  • your endpoint responds within 3 seconds.
Events are dropped, not queued, in these cases:
  • Deliveries active was off when the event happened.
  • All three delivery attempts failed. Edplay does not redeliver afterwards.
  • The event type is not selected under Events.
For any gap longer than a couple of minutes, backfill through the API rather than waiting for a redelivery that will not come.
This is expected. A retry can deliver an event you already processed, for example when you returned 200 just after the 3-second limit. course.progress_updated also fires repeatedly by design.Deduplicate on user.id plus course.id plus occurred_at, or make your write naturally idempotent.

Still stuck?

Open the failing row in the delivery log and copy its UUID, then send that and the approximate timestamp to dev@edplay.ai. That is enough for us to trace the call end to end.