Get Webhook Call

GET /webhook-calls/{call_id}

One delivery, whole: the payload we stored, what we answered, and why.

admin where the listing beside it is viewer, and that asymmetry is the contract’s rather than an oversight — but it is not arbitrary either. Both carry request_payload today, so the honest reading is that the detail is the row somebody reaches for when they want the partner’s body, and annex 05 §4.7 puts that behind the higher floor.

Role floor

Requires admin or above. The floor is a minimum, not a grant: scope filtering still applies on top of it, and a resource in another tenant answers 404 rather than 403.

Parameters

Name	In	Type		Notes
call_id	path	string (uuid)	required	—

Responses

Status	Description	Body
200	Successful Response	WebhookCallView
422	Validation Error	HTTPValidationError

Only the success paths are declared

Any operation may also answer any status in the error catalogue, and every failure body is the platform envelope — including the 422 this document types as HTTPValidationError.

Example

curl -X GET https://your-deployment.example.com/webhook-calls/{call_id} \
  -H "Authorization: Bearer $COBRE_TOKEN"

Response — WebhookCallView

Field	Type		Notes
id	string (uuid)	required	—
endpoint_id	string (uuid) | null	required, nullable	—
endpoint_slug	string | null	required, nullable	—
received_at	string (date-time)	required	—
http_method	POST | GET | PUT	required	—
matched	endpoint | event_kind | none	required	—
outcome	accepted | rejected | failed | timeout	required	—
http_status	integer | null	required, nullable	—
latency_ms	integer | null	required, nullable	—
signature_present	boolean	required	—
client_ip	string | null	required, nullable	—
request_bytes	integer | null	required, nullable	—
request_payload	object | null	required, nullable	—
response_body	object | null	required, nullable	—
run_ids	object[]	required	—
error_message	string | null	required, nullable	—
replay_of_id	string (uuid) | null	required, nullable	—