> ## Documentation Index > Fetch the complete documentation index at: https://yuno-3979e326-fix-create-subscription-card-usage.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Configure Webhooks ## Setup You can configure webhooks using the [Yuno dashboard](https://dashboard.y.uno/): 1. Navigate to the **Developers** tab 2. Click **Webhooks** 3. Click **Add webhook** A sidebar will open where you'll configure: * **Name**: Identify your webhook * **Endpoint URL**: Your server URL to receive notifications * **x-api-key**: Your API key (sent in notification headers) * **x-secret**: Your secret (sent in notification headers) * **Use OAuth2 Authentication**: Optional checkbox for OAuth2 * **Use HMAC Authentication**: Optional checkbox for HMAC signature verification **Trigger on**: Select which events will trigger this webhook (enrollment, payment, subscription, etc.) Once configured, the webhook will send notifications whenever the selected events occur. The image below shows the side panel to add a webhook. In the [Yuno dashboard](https://dashboard.y.uno/) Developers tab, you can activate and deactivate webhooks using the **Status** toggle button. Access the [Webhooks Examples](/docs/object-and-examples) page to check examples for payment, enrollment, and many other notification events. ### HMAC authentication When you enable **Use HMAC Authentication** in the dashboard, you'll provide a client secret key. Yuno will use this key to generate an HMAC signature and send it in the `x-hmac-signature` HTTP header with each webhook request, allowing you to verify that webhooks genuinely come from Yuno and haven't been tampered with. See the [Verify Webhook Signatures (HMAC)](/docs/verify-webhook-signatures-hmac) guide for implementation details. ### oAuth2 When you enable **Use OAuth2 Authentication** in the dashboard, you can configure the following parameters so Yuno can obtain the authorization token that will be sent in the webhook headers: * `Authentication_url`: url to use for authentication * `Credentials`: Necessary credentials to communicate with the authentication\_url. * Client Secret\_key * Cliente Client\_ID * `Grant type`: Type of grant for the authentication. ## Receipt confirmation process Yuno webhooks expect to receive an HTTP 200 OK status as a response to indicate that the webhook was received. The merchant system response does not need to provide any information on the body request, only the HTTP 200 status. In case of not receiving a response at the specified time, Yuno webhooks will send the event notification up to seven times to avoid information loss. The table below presents the webhooks notification schedule and the confirmation waiting time.
Event Deadline after the first try
First try *
Second try 5 minutes
Third try 50 minutes
Fourth try 6 hours
Fifth try 24 hours
Sixth try 48 hours
Seventh try 96 hours
## Webhooks event types Depending on the type of event, you will receive a different type of webhook and event. The next table presents the possible event types for enrollments and payments currently available. | type | type\_event | | :------------------------ | :--------------------------------- | | enrollment | enroll | | enrollment | unenroll | | enrollment | expiration | | enrollment | update | | payment | purchase | | payment | authorize | | payment | capture | | payment | refund | | payment | cancel | | payment | verify | | payment | chargeback | | payment | fraud\_screening | | payout | payout | | subscription | create | | subscription | active | | subscription | paused | | subscription | resumed | | subscription | canceled | | subscription | completed | | subscription | error | | onboarding | create | | onboarding | pending | | onboarding | pending\_additional\_documentation | | onboarding | pending\_recipient\_action | | onboarding | succeeded | | onboarding | canceled | | onboarding | declined | | onboarding | rejected | | onboarding | blocked | | onboarding | unblocked | | onboarding | error | | onboarding | expired | | onboarding | failed | | split\_transfer | succeeded | | split\_transfer | failed | | split\_transfer\_reverse | succeeded | | split\_transfer\_reverse | failed | | banking.entity | created | | banking.entity | updated | | banking.entity | deleted | | banking.onboarding | created | | banking.onboarding | pending | | banking.onboarding | pending\_additional\_documentation | | banking.onboarding | succeeded | | banking.onboarding | failed | | banking.onboarding | declined | | banking.onboarding | cancelled | | banking.onboarding | expired | | banking.account | created | | banking.account | updated | | banking.account | activated | | banking.account | closed | | banking.transfer | pending | | banking.transfer | processing | | banking.transfer | completed | | banking.transfer | failed | | banking.transfer | cancelled | | banking.transfer | reversed | | banking.transfer.incoming | pending | | banking.transfer.incoming | completed | > `subscription.active` is sent only when a subscription transitions from any other valid status into `ACTIVE`. No webhook is emitted if the subscription is already active. ### Fraud Screening Webhook Behavior When a transaction is declined by the fraud screening and doesn't move forward to processing with any provider, no transactions are created — the `transactions` array comes back empty. In this case, the only elements that get created are within the `fraud_screening` object, and the webhook that's triggered is `payment.fraud_screening`. If due to the routing configuration the fraud screening declines but the transaction still proceeds to processing, the event sent to the client is `payment.purchase`.