Retries and 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).

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.

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.

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 is essential.

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