# Retries and logs

> When Rapid tries to deliver the webhook again, at what intervals, what counts as success and how to read the delivery log.

Página: https://doc.rapidchargeback.com/en/canais/webhook/retries-e-logs/

## Retry policy

If your application responds with any code other than `2xx`, or does not respond within the timeout, Rapid considers the attempt a failure and sends the webhook again.

There are **4 attempts** in total: the initial one plus 3 more, each waiting longer than the previous one.

1. **Right away** 1st attempt, as soon as the event is queued
2. **+5 min** 2nd attempt, 5 minutes after the previous failure (5 minutes from the start)
3. **+15 min** 3rd attempt (20 minutes from the start)
4. **+30 min** 4th and last attempt (50 minutes from the start)

If the 4th also fails, the delivery is closed and the alert stays available in the dashboard for manual action (see [Manual redelivery](#manual-redelivery)).

## Timeout

Each attempt has a **30-second timeout**. If your application does not respond within that time, the attempt is considered a failure.

## What counts as success

Any **`2xx`** code: `200`, `201`, `202`, `204` and the rest of the range. The response body is optional.

Any other code (including `4xx` and `5xx`) triggers a retry.

### Redirects

Register the **final URL**. Rapid handles redirects like this:

| Your URL's response | What happens |
|---|---|
| `301`, `302`, `303` | **Failure.** These codes turn the POST into a `GET` and drop the body, so following them would deliver nothing. The attempt goes into the retry flow and the log shows where your URL redirects to. |
| `307`, `308` to the **same** domain | Followed, with the POST, body and headers intact. Up to 3 redirects in a row. |
| `307`, `308` to **another** domain | **Failure.** The signed payload does not leave the domain you registered. |

The common cases are the server appending `/` to the end of the path and switching domains, such as from `example.com` to `www.example.com` (which counts as another domain). In the delivery log, the reason starts with `[redirecionamento]`, along with the destination address.

## Address that is not public

If the registered address does not resolve to a public internet address (it points to a local or private network, or the domain does not exist), the delivery **fails without any request** and goes into the normal retry flow. In the delivery log, the reason starts with `[destino]`. Fix the URL or the domain's DNS; see [Use a public internet address](https://doc.rapidchargeback.com/en/canais/webhook/boas-praticas/#use-a-public-internet-address).

If the reason starts with `[https]`, the registered URL does not use HTTPS and Rapid does not deliver in plain text: register an `https://` URL.

If the reason starts with `[assinatura]`, the failure is on Rapid's side: the delivery does not go out unsigned, and it is retried automatically. There is nothing to do in your system.

## Blocked companies

If the company is blocked for non-payment at Rapid, **the webhook flow keeps working normally**: alerts are still received from the providers, stored and delivered to the configured URL. The dashboard remains available. What the block cuts off is the **credential-based API** (read and write: `GET/PATCH /chargeback-alert/alerts`, transactions, merchants, legacy aliases), which starts responding `403 COMPANY_BLOCKED`, and the defense of new disputes.

To stop receiving new alerts, the enrollment has to be deactivated directly at the provider (an action carried out by the Rapid team).

## Delivery logs

Every attempt is recorded internally with:
- Event delivered (`chargeback_alert.received`, `dispute.fraud.revoke_access`)
- Date and time of the attempt
- Destination URL
- HTTP response code
- Response body (truncated at 1000 characters)
- Attempt number

You see these records in the Rapid dashboard in two places: in **Settings › Webhook**, under **Delivery history**, the most recent deliveries; in **Activity**, **Webhooks** tab, the full history for debugging failures. When the failure never reached your server, the dashboard shows an explanation of the reason; the original text, which starts with `[https]`, `[destino]`, `[redirecionamento]` or `[assinatura]`, appears on hover.

## Manual redelivery

When every automatic attempt fails, the alert stays in the dashboard. To send it again, use the **Retry** button in the **Delivery history**, under **Settings › Webhook**. The redelivered event arrives as a new webhook with the same `alert_id`, which is why [idempotency](https://doc.rapidchargeback.com/en/canais/webhook/boas-praticas/#idempotency) is essential.

Redelivery from the dashboard applies to alerts. The `dispute.fraud.revoke_access` event has no manual redelivery.