Device Rescue automatically logs webhook activity to help you monitor, troubleshoot, and verify event deliveries to your external systems.
Webhook logs capture key information for each event, including the full request and the response from your server.
Where to Find Webhook Logs
-
Go to Account Settings → Webhooks & API → Webhook Logs
-
Use the Environment dropdown to select:
-
Test – Webhooks triggered in the test environment
-
Production – Webhooks triggered in the live environment
-
What Webhook Logs Display
For each event, the logs show:
-
Status – Success, Retrying, or Failed
-
Event ID – Unique identifier for the webhook event
-
Event Type – The action that triggered the event (e.g.,
asset.note.created
) -
Response Code – The HTTP response received from your server (e.g., 200 OK, 405 Not Allowed)
-
Date/Time – When the webhook event occurred
Expanding a Log Entry
Click Details to expand a webhook event and view:
-
Request:
-
URL
-
Headers (including your Webhook Secret and Signature for validation)
-
Full JSON Payload that was sent
-
-
Response:
-
HTTP status code
-
Body returned by your server
-
This helps you fully audit both sides of the webhook interaction.
Webhook Log Retention Periods
-
Test Environment Logs – Retained for 7 days
-
Production Environment Logs – Retained for 30 days
After these periods, older logs will be automatically deleted.
How Webhook Retries Work
If a webhook event fails (your server responds with a non-2XX code like 4XX or 5XX):
-
Device Rescue will retry the event up to 3 times
-
Retries are spaced out with increasing delay intervals
-
After the third failed attempt, the event will be marked as permanently failed
🔁 Tip: Check your server’s response codes and error handling if you notice retries or failures.
Best Practices
-
Monitor your webhook logs regularly, especially after deploying API changes
-
Ensure your webhook endpoint always responds with HTTP 2XX to avoid unnecessary retries
-
Validate incoming requests using the provided Webhook Secret
📢 Note: Webhook events are designed for reliability, but it's important to build idempotent endpoints that can safely handle retries.