Webhooks

The Webhooks area lists the addresses registered by the company to receive notifications and the events selected for each destination. Go to

Integration, Webhooks. Each registration belongs to the selected environment.

Sandbox and Production events are sent to destinations registered in their respective environments. Sandbox uses test data but makes a real HTTPS request to your endpoint. Use a separate test destination to prevent a simulation from changing your Production system.

See Receive and validate events to implement the receiver, validate the signature, and handle redeliveries.

To manage the same registrations from your system, use the Webhooks API. The integration can also query deliveries and attempts.

Viewing requires Webhooks. Creating, renaming, editing the URL and events, pausing the queue, disabling, re-enabling, rotating, and deleting have their own permissions and may be blocked when the account is in view-only mode.

If your endpoint restricts request sources, add the official Raims IPs to the allowlist before receiving webhooks.

Register a webhook

Events available in the Dashboard

The form organizes events into charges and refunds. The names below identify the categories selected during registration. Selecting a type does not create an occurrence. Delivery depends on confirmation of the corresponding event.

Latest webhook activity

Last activity shows the time of the latest recorded delivery attempt, including failed attempts. This time does not confirm that the endpoint received or processed the event and may take a while to appear.

No record means there is no confirmed attempt available to display. It does not prove that no deliveries have ever been sent. Unavailable means the information could not be retrieved at that moment; try again later.

Older activity may remain visible even when that attempt's logs are outside the available lookup period. Access to this information requires only Webhooks; viewing logs has its own permission.

To investigate a failure episode through the API, use Check webhook health. This query shows the available times and duration of recorded failures without testing the receiver URL.

Protect the secret

The complete secret is authentication data. Store it in your application's private environment and limit access to those who manage the integration. The webhook identifier does not replace this secret.

To check the authenticity of each request, follow signature validation using the original received body.

Do not send the secret to support or include it in screenshots. If you suspect exposure, rotate the secret and update the configuration using it. Query the current charge or refund state through the API before making a financial decision.

Rename a webhook

1. Go to Integration, Webhooks and open the destination's actions.
2. Select Rename webhook, enter the new name, and confirm the change.
3. Check the updated name in the list.

This action requires Edit webhooks. Renaming does not change the URL or events.

Edit URL and events

The Edit URL and events action changes the receiving address and event selection for the same registration. It requires Webhooks and Edit webhook URLs and events, plus the identity confirmation requested by the Dashboard. The URL follows the registration rules, and at least one event must remain selected.

The name, identifier, secret, and status are preserved. Editing the configuration does not re-enable a disabled webhook, reset the failure count, or extend retry deadlines.

Changes apply to subsequent selections and delivery attempts. Removing an event type stops authorizing it for new sends. Requests already authorized or in progress may finish with the previous configuration. Adding a type may also send earlier events that were still waiting to be prepared. Editing does not resend completed deliveries.

Previously selected events may be kept or removed even when they are no longer available for new registrations. If you remove one of these events and save, it cannot be selected again while it remains outside the current catalog.

Pause and resume the queue

Use Pause queue in the webhook menu before maintenance on the receiver. Check the notice and complete identity confirmation. This action requires Webhooks and Edit webhook URLs and events and is available for an active registration.

The Queue paused indicator confirms the setting. Pending deliveries and newly selected events wait, but their deadlines continue counting down: up to 72 hours in Production and four hours in Sandbox. Requests already authorized may finish. If a delivery expires during the pause, it will not be sent when the queue resumes.

After maintenance, choose Resume queue from the same menu and confirm. Deliveries that remain valid become eligible to be sent again, subject to delivery limits. Resuming does not guarantee immediate delivery or a specific order. Pausing and resuming close the previous failure episode without proving that the receiver has recovered. Check the results in the logs.

To control the pause from your integration, use Pause or resume the queue. You can request a technical test during the pause to check the receiver before resuming.

Disable and re-enable a webhook

The Disable webhook and Re-enable webhook actions require Edit webhooks and the identity confirmation requested by the Dashboard. They preserve the registration, secret, and selected events.

A disabled webhook receives no new sends. If a pending attempt finds the registration disabled, that delivery is closed. Re-enabling it before that attempt allows delivery to continue within its original deadline. The action does not resend history or automatically recover closed deliveries. Manual resend lets you request another delivery for an eligible event.

For maintenance that preserves deliveries that remain valid, use Pause and resume the queue. If a registration is disabled while the queue is paused, re-enabling it preserves the pause; use Resume queue to allow sends.

Failures do not automatically pause or disable the registration. Fix the receiver and follow new attempts, which continue within each delivery's limits. See Webhook failures and retries and failure alerts.

Rotate the signature

1. Go to Integration, Webhooks and open the correct destination's actions.
2. Select Rotate signature.
3. Check the notice, confirm the rotation, and store the new secret.
4. Update the receiver and check that it accepts events signed with the new secret.

This action requires Rotate webhooks and keeps the registration identifier. In the Dashboard, replacement is immediate: new sends use only the new secret as soon as rotation is confirmed. If a transition was started through the API, rotating in the Dashboard also ends that transition and replaces both previous secrets.

Update the receiver to avoid rejections. Requests already authorized or in progress may still arrive with a previous signature. If a secret was exposed, also remove the old secrets from the receiver's configuration. Rotation does not re-enable a disabled webhook or reset the failure count.

The API lets you choose a transition period for a planned change. The Dashboard does not use this option.

Delete a webhook

1. Go to Integration, Webhooks and open the actions for the destination you want to remove.
2. Select Delete webhook, check the destination, and confirm deletion.
3. Wait for the result and check the list.

This action requires Delete webhooks and permanently removes the destination. First check whether a system depends on it. Deletion prevents new sends to that registration. Requests already authorized or in progress may still finish.