Every time a live input or an asset emits an event, ClutchCall records a delivery: one row per attempt to hand that event to one of your endpoints. The Request logs screen renders those rows. This page explains the record’s fields, how its state is decided, and what a resend does. The log is read-only history plus a per-row resend. Endpoint configuration (URLs, which event types an endpoint subscribes to) is not part of the delivery record and is managed on the Webhooks page.

​
The delivery record and its fields

Each row returned by streams.eventDeliveries.list is a single delivery record: Rows in this log routinely span several days, so the console formats ts with month and day as well as hour and minute rather than time alone.

​
Queued, delivered and failed: how a state is decided

There is no single state column. The console derives the badge from response_code and status together: Two consequences are worth internalising:
  • A delivery that has not been attempted yet, or is mid-flight, is queued, not failed. It is not painted red and it is not counted as a failure.
  • A record with status === "failed" and no response_code renders as — ERR. That is the shape of a failure where no HTTP status came back at all (the request never completed), as opposed to a 4xx/5xx answer from your server.

​
What the attempt counter counts

attempt is the attempt number carried on the delivery record. A row with an attempt greater than 1 tells you that this event took more than one try to reach the endpoint. When the field is absent the console displays 1. The record does not carry a retry schedule, a next-attempt time, or a remaining-attempts budget — none of those are fields on the delivery, so you cannot read “when will it retry again” off this screen. Treat the attempt number as history, not as a prediction.

​
Resending an event and what the consumer sees

The resend control on each row acts on a single delivery: it takes the org id and that row’s id. There is no bulk or time-range replay on this screen, and a resend is scoped to your org. Plan your handler around two properties:
  • At-least-once, not exactly-once. A resend hands your endpoint the same event_type for the same obj_id again. A handler that creates records, sends notifications, or increments counters must be idempotent. Key it on identity from the event itself rather than on “have I seen a request before”.
  • No ordering guarantee. A resend is dispatched when you click it, so a replayed event arrives after events that were originally emitted later than it. Do not infer state transitions from arrival order; reconcile against the object’s current state or the timestamps inside the event payload.
The screen re-queries the delivery list every 30 seconds, so the outcome of a resend surfaces in the log on the next poll rather than instantly.

​
Listing and paging deliveries over the API

The procedure returns a flat array of delivery records, newest first. It returns no total count and no cursor. The console detects a further page by checking whether the returned array is exactly limit long; if it is shorter, this is the last page and Next is disabled. That is also why the “All” filter label renders as 100+ rather than an exact total when a full page comes back.

​
Filters apply to the page you loaded

The All / Delivered / Failed buttons filter client-side over the records already fetched for the current page. They are not query parameters:
  • Delivered keeps rows whose response_code is in 200–299.
  • Failed keeps rows that are neither delivered nor queued.
  • The failure count next to the Failed button counts failures in the loaded page only — not across your whole history.
To audit further back, page through with Prev / Next and apply the filter per page.

​
Which objects appear in the log

The obj_id column is the id of the live input or asset that emitted the event, and the event_type column is the event’s name. An org with no deliveries yet sees an empty log: events from your live inputs and assets appear here as they fire, once at least one endpoint is configured to receive them.