Skip to main content
Every webhook Nudj sends — successful or not — is persisted to a dedicated log collection. You can query the log via the Admin API, or inspect it in the admin panel and re-trigger failed deliveries with one click.
Delivery logs are organisation-scoped. You need an Admin-tier API token to read them.

​
When are logs written?

Nudj writes a log record each time it attempts to deliver a webhook:
  • On the initial attempt, whether the endpoint returns 2xx or not.
  • On each automatic retry (up to your configured maxRetries).
  • On any manual retry triggered from the admin panel or API.

​
Log record shape

{
  "id": "652f8a3c1e4f7d0012a3b4c5",
  "webhookConfigId": "650c9e1a...",
  "organisationId": "5f7d1e2a...",
  "eventSubCategory": "challenge-completion",
  "url": "https://your-app.com/webhooks/nudj",
  "httpMethod": "POST",
  "requestHeaders": { "Authorization": "Bearer ***", "X-Webhook-Source": "nudj-platform" },
  "requestBody": { "id": "...", "eventCategory": "challenge", "userId": "...", "payload": { /* ... */ } },
  "responseStatus": 500,
  "responseHeaders": { "content-type": "text/plain" },
  "responseBody": "Internal Server Error",
  "attempt": 2,
  "success": false,
  "errorMessage": "HTTP 500: Internal Server Error",
  "createdAt": "2026-03-14T10:21:45.102Z"
}
Secret values in requestHeaders are redacted in the stored record.

​
Query logs via the API

Use the Admin API endpoint to page through recent delivery attempts: 
curl -X GET "https://{subdomain}.nudj.cx/api/v2/admin/webhooks/logs?limit=50" \
  -H "x-api-token: YOUR_ADMIN_API_TOKEN"
See GET /webhooks/logs for filter options (by eventSubCategory, success, date range, etc.).

​
Retry a failed delivery

In the admin panel, navigate to Settings → Organisation → Webhooks → Delivery Logs and click the Retry icon next to any failed row. Nudj will resend the exact same payload to your endpoint and write a fresh log entry with attempt: N+1.
Manual retries do not count against your configured maxRetries. Don’t loop retries programmatically — fix the root cause first, then retry.

​
Use cases

  • Debugging a broken handler: compare requestBody to what your handler received. Check if a reverse proxy, payload size limit, or JSON parser is stripping fields.
  • Replaying events after downtime: your endpoint was down for 10 minutes? Filter logs by success: false and retry each one.
  • Auditing: prove to internal stakeholders that a specific event was delivered with the exact payload and response.

​
Retry semantics

Automatic retries use a fixed 5-second delay and stop after the webhook’s maxRetries value (default 3). There is no exponential backoff today — if your endpoint is flapping, use the manual retry flow once the root cause is fixed instead of relying on auto-retry. Every retry attempt — automatic or manual — gets its own log entry, so you can trace the exact delivery timeline per event.

Troubleshooting

Diagnose common delivery failures.

Implementation Guide

Build a compliant handler from scratch.