Skip to content

↑↓ navigate ↵ open Ctrl↵ new tab esc close

Updates the status of an alert received by webhook.

PATCH https://api.rapidchargeback.com/api/v1/chargeback-alert/alerts/:id/status
Authorization: Basic base64(client_id:client_secret)
Content-Type: application/json

ParameterTypeDescription
idstring (UUID)alert_id received in the webhook payload

FieldTypeRequiredDescription
statusstringYesOne of three values: notfound, account_suspended, other

  • status must be exactly one of the three valid values; anything else returns 422
  • The alert must belong to your company; otherwise it returns 404
  • Final statuses (notfound, account_suspended) cannot be changed once sent; trying returns an error
  • The expired status is set automatically by the system after 24h with no response (Ethoca) and is not sent by the customer
  • The only transition allowed after the initial response is other → account_suspended, available for up to 6 days (Ethoca)

See Rules and deadlines for the full detail.


The credentials come from environment variables (RAPID_CLIENT_ID and RAPID_CLIENT_SECRET), never written in the code.

Terminal window
curl -X PATCH https://api.rapidchargeback.com/api/v1/chargeback-alert/alerts/00000000-0000-0000-0000-000000000099/status \
-H "Authorization: Basic Y2xpZW50X2lkOmNsaWVudF9zZWNyZXQ=" \
-H "Content-Type: application/json" \
-d '{
"status": "account_suspended"
}'

{
"data": {
"id": "00000000-0000-0000-0000-000000000099",
"status": "account_suspended",
"updated_at": "2026-04-14T14:30:00.000Z"
}
}
{
"error": {
"code": "ALERT_NOT_FOUND",
"message": "Alert not found"
}
}
{
"error": {
"code": "COMPANY_BLOCKED",
"message": "Company is blocked"
}
}

When the status sent is not one of the three accepted values, body validation fails before processing and returns VALIDATION_ERROR (HTTP 422):

{
"error": {
"code": "VALIDATION_ERROR",
"message": "Invalid enum value. Expected 'notfound' | 'account_suspended' | 'other', received 'foo'"
}
}

When the status is valid but the transition is not allowed (deadline, expiration or status already final), the code is ALERT_INVALID_STATUS (HTTP 422). The message says which of the three cases happened:

{
"error": {
"code": "ALERT_INVALID_STATUS",
"message": "Alert has expired"
}
}
{
"error": {
"code": "ALERT_INVALID_STATUS",
"message": "Response deadline has passed"
}
}
{
"error": {
"code": "ALERT_INVALID_STATUS",
"message": "Alert already has a definitive status"
}
}

These three only happen for Ethoca alerts; Verifi RDR has no deadline rules (see Rules and deadlines).


If you integrated with the previous version of the platform, the old endpoint is still available as an alias:

POST https://api.rapidchargeback.com/chargeback-alert/update/status

This alias accepts the body in the old format { "alert_id": "...", "status": "..." } and both Basic Auth and the clientid/clientkey headers. As in the previous system, alert_id is the alert ID at the provider (the same alert_id you receive in the legacy webhook format and use in POST /chargeback-alert/get); Rapid’s UUID is also accepted. The response keeps the old format { "success": true, "message": "...", "status": "..." } and adds data with the object of the canonical endpoint. Errors follow the new envelope (422 VALIDATION_ERROR / ALERT_INVALID_STATUS, 404 ALERT_NOT_FOUND).

Recommendation: migrate to PATCH /chargeback-alert/alerts/:id/status. The alias will be removed in the future, once there are no more calls to it.