> ## Documentation Index
> Fetch the complete documentation index at: https://apidocs.paylias.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# Implementation Flow

> Create webhook subscriptions through the dashboard or through the API

A typical flow to implement Paylias webhooks within your application may look like the following

1. Use the dashboard or the [Create Webhook](api-reference/webhooks/create-webhook) endpoint to subscribe to a single or multiple events.
2. If you have decided to opt in for webhook signature verification, implement your application logic for [Webhook Event Signature Verification](/concepts/webhooks/signature-verification).
3. Enable your webhook subscription through the [Update Webhook](api/reference/webhooks/update-webhook) endpoint if you haven't already done so.
4. Trigger events by [Creating a payment](/api-reference/payments/create-payment) to test the logic for receiving events from Paylias. You can [view event delivery logs](/api-reference/webhooks/list-events) and [delivery-errors](/api-reference/webhooks/list-delivery-errors) both through the API as well as on the dashboard.

## Subscribing to events

Events in Paylias are structured as a JSON object with two keys:

1. `record_type`: This is the resource for which the event is being triggered
2. `event_type`: This is the operation on the resource that triggered the event.

Currently Paylias supports the following combination of `record_type`s and `event_type`s

| record\_type               | EK\_Created | EK\_Updated |
| -------------------------- | ----------- | ----------- |
| `RT_Payments`              | yes         | yes         |
| `RT_PaymentSubmissions`    | yes         | yes         |
| `RT_PaymentAdmissions`     | yes         | yes         |
| `RT_PaymentAdmissionTasks` | yes         | yes         |
| `RT_Error`                 | yes         | no          |
| `RT_Transactions`          | yes         | no          |

When creating a webhook subscription, you can have a single endpoint subscribe to a single or multiple combinations of `record_type:event_type` depending on your own internal use cases and logic handling.

<Note>While a single endpoint can subscribe to multiple events, an event can only be subscribed to a single endpoint. This means that if you already have an active subscription for a specific combination of `record_type:event_type` for example `RT_Payments:EK_Created`, you cannot resubscribe to this event through another endpoint.</Note>