> For the complete documentation index, see [llms.txt](https://docs.caf.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.caf.io/caf-api/connect/webhook/managing-webhooks.md).

# Managing Webhooks

After creating your webhooks, you can monitor their activity, view event details, and manage their configuration through the Trust portal.

## Managing existing webhooks

### Viewing webhook configuration

In the webhooks list, each webhook displays:

![Webhook Management](/files/HF1vFvXXOPSGxsjvMYUI)

* **Payload URL**: The endpoint where webhooks are sent
* **Status**: Whether the webhook is Active or Inactive
* **Actions**: Options to view events, edit, or delete the webhook

To access webhook events, click the **View events** button for any webhook.

## Viewing webhook events

### Webhook events list

After clicking **View events** from the webhook management page, you can see all recent webhook deliveries for that specific webhook:

![Webhook Events](/files/lNhcp6Auywk9PWEW1xnw)

The webhook events page displays:

* **Event ID**: Unique identifier for each webhook delivery attempt
* **Event Type**: The type of event that triggered the webhook (e.g., `COMMUNICATION.COMMUNICATIONCREATEDEVENT`)
* **Date**: When the webhook was sent
* **Status**: Visual indicator showing successful (✓) or failed (✗) delivery
* **Event details**: Link to view detailed information about the webhook delivery

{% hint style="info" %}
Trust may display the event with its source prefix, such as `TRANSACTION.TRANSACTIONSTATUSUPDATEDEVENT`. In the delivered CloudEvent payload, these values are separate: `source` is `TRANSACTION` and `type` is `TRANSACTIONSTATUSUPDATEDEVENT`.
{% endhint %}

### Event details

Click on **Event details** for any webhook delivery to see comprehensive information:

![Event Details](/files/ZmeanEKt5rpeN6uatY50)

The event details page shows:

#### Request Tab

* **Payload**: The complete `JSON` payload that was sent to your webhook endpoint
* **Headers**: `HTTP` headers included in the webhook request

#### Responses Tab

* **Response Status**: `HTTP` status code returned by your endpoint
* **Response Headers**: Headers returned by your webhook endpoint
* **Response Body**: The response body from your endpoint

You can use the **Resend** button to retry failed webhook deliveries. Note that the **Resend** button is only available for webhooks that failed (marked with ✗).

### Understanding webhook delivery status

* **✓ Green checkmark**: Webhook was successfully delivered (HTTP 2xx response)
* **✗ Red X**: Webhook delivery failed (non-2xx response, timeout, or connection error)

### Redelivering failed webhooks

For failed webhook deliveries (marked with ✗), you can manually retry the delivery:

1. Click on **Event details** for the failed webhook
2. Review the failure reason in the Responses tab
3. Click the **Resend** button to retry the delivery
4. The webhook will be sent again with the same payload and headers

{% hint style="info" %}
**Resend Availability**

The **Resend** button is only available for failed webhook deliveries. Successfully delivered webhooks (marked with ✓) cannot be resent, as they have already been processed successfully.
{% endhint %}

### Editing webhooks

Click the "Edit" button to modify webhook settings:

![Edit Webhook](/files/TJLwoIKxkvvnh869aRkw)

You can update:

* **Payload URL**: Change the destination endpoint
* **Secret**: Update the webhook signature secret
* **Authentication type**: Modify authentication method (None, Basic, API Key)
* **Event selection**: Change which events trigger the webhook
* **Active status**: Enable or disable the webhook

### Troubleshooting failed webhooks

When webhooks fail (marked with ✗), check the event details to understand why:

1. **4xx Errors**: Usually indicate issues with your endpoint
   * 404: Webhook URL not found
   * 401/403: Authentication issues
   * 400: Your endpoint rejected the payload format
2. **5xx Errors**: Server errors on your endpoint
   * 500: Internal server error in your webhook handler
   * 502/503: Your server is unavailable
3. **Timeout**: Your endpoint took too long to respond (> 2 seconds)

### Best practices for webhook management

{% hint style="success" %}
**Monitoring Recommendations**

* Regularly check the webhook events page for failed deliveries
* Set up monitoring alerts for your webhook endpoints
* Use the "Resend" feature to retry failed webhooks after fixing issues on your endpoint
* Keep webhook URLs up to date when your infrastructure changes
* Remember that "Resend" is only available for failed deliveries - successful ones don't need to be resent
  {% endhint %}

{% hint style="info" %}
**Event Retention**

Webhook event details are retained for monitoring and debugging purposes. Use this data to:

* Debug integration issues
* Monitor webhook delivery success rates
* Understand event patterns and timing
  {% endhint %}

## Next steps

* [Learn about webhook events](/caf-api/connect/webhook/events.md) to understand payload structures
* [Implement signature verification](/caf-api/connect/webhook/signature.md) for security
* [Follow best practices](/caf-api/connect/webhook/best-practices.md) for reliable webhook handling


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.caf.io/caf-api/connect/webhook/managing-webhooks.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
