Skip to main content
Help Center

Webhook Edge Cases and Recommendations

Ordering tips for received vs updated events and how to handle webhooks enabled mid-stream.

Enabling webhooks after requests already exist

If you turn on webhooks after some requests arrived, you may see privacy_request.updated events without a matching privacy_request.received. Correct those requests manually, or start recording new requests only after in-transit items settle. If you need Optacy to replay webhooks for historical requests, contact us.

Updated before received

Sometimes privacy_request.updated arrives soon after receipt (for example when the MP3 or transcription becomes available) and can race ahead of privacy_request.received.

Recommended pattern:

  1. Create the privacy request record when you receive privacy_request.received.
  2. Apply updates from privacy_request.updated using the signature timestamp (keep the newest state).

If you receive privacy_request.updated first, return a non-200 response (for example a PrivacyRequestNotFound error). Optacy will automatically retry about 30 minutes later. This is uncommon, but when it happens you can also:

  • use locking on a parent record such as a Service Code
  • upsert based on the latest timestamp
  • queue failed updates and retry them on your side after the received event lands