Skip to main content
Webhook delivery attempts record every time Risk Cloud tried to send a webhook payload to your endpoint, whether the delivery was automatic (including automatic retries) or a manual replay. This endpoint requires the Webhook Observability feature; contact your LogicGate representative to enable it. For background on webhook URLs themselves, see Interacting with Webhooks via Endpoints.

​
Retrieve Webhook Delivery Attempts endpoint

Requires Build permission. Requests without it are rejected with 403. If Webhook Observability is not enabled on your account, requests are rejected with 400. Which attempts you can see also depends on which Applications you’re entitled to. See Which attempts you see below.

​
Query parameters

All filters are optional. Omit one to match all values. When you supply more than one, they’re combined with AND. Sortable fields: fireDate, status, attemptType, httpStatusCode, webhookName, webhookUrl, webhookId, jobId, jobName, recordId, recordName, jobExecutionOperationId.
An unrecognized sort field is accepted rather than rejected, but the resulting order is unspecified. Check your spelling if results come back in an unexpected order. The fireDate,desc default only applies when you supply no sort at all; it isn’t added as a tiebreaker to a sort you provide. Sorting by a field with many repeated values (such as status) won’t produce a stable order across pages unless you add fireDate,desc as a final sort criterion.
Request body: none.

​
Response

200 OK. Attempts are returned in content, alongside standard pagination metadata. See Pagination for details on the page response envelope.

​
Attempt fields

When and how the attempt happened What your endpoint returned Both are null when no response was received at all, such as a timeout, a DNS failure, or a refused connection. If your endpoint responded but rejected the request, both are populated and status is FAILED. Which webhook, job, and record were involved Each of these may be null. These seven fields are recorded at the time of the attempt and never updated afterward:
  • Renaming a webhook, job, or record does not change attempts already recorded. Older entries keep the names that were in effect when they were sent.
  • Attempts are retained after the webhook, job, or record they reference is deleted. An ID in a response is therefore not a guarantee that the item still exists.

​
Which attempts you see

Results are limited to attempts from jobs you’re entitled to.
  • With Admin permission, you see every attempt in the account.
  • With Build permission only, you see attempts from a job when any of the following is true:
    • the job runs on a fixed schedule; or
    • the job is triggered from a Workflow whose Application has no permissions restrictions; or
    • you’re entitled to the Application the job is triggered from.
If none of your jobs qualify, the response is 200 with an empty content array rather than an error.
Two common sources of confusion when results are emptier than expected:
  • Application entitlement is separate from step permissions. Having full permissions on every step of an Application does not by itself make that Application’s jobs visible here. You need entitlement to the Application itself.
  • The Application that matters is the one the job is triggered from, the Application containing the Workflow the job’s trigger watches. It is not necessarily the Application of the record in the response.
Attempts are also excluded once the job that produced them has been deleted.

​
Errors

This endpoint does not return 404. A valid request that matches nothing returns 200 with an empty content array.

​
Historical coverage

Delivery attempts are recorded from the point Webhook Observability became active on your account onward. Webhook activity from before then is not available through this endpoint and cannot be backfilled. A newly enabled account returns no attempts until its next webhook delivery.