Reverse-Redeem User Reward

Recent Requests
Log in to see full request history
TimeStatusUser Agent
Retrieving recent requests…
LoadingLoading…

This API reverses a redemption, moving every user reward in the transaction from the REDEEMED state back to ISSUED.

Use it to undo a redemption that was recorded in error, for example when a voucher was marked as redeemed by mistake or a return/exchange means the reward should become usable again. Only transactions in the REDEEMED state can be reverse-redeemed.

The endpoint is gated by the brand-level REVERSE_REDEEM_ENABLE configuration flag, which is false by default. Raise a ticket with Product support to enable this for your organisation.

👍

Note

  • For detailed information about our APIs and for hands-on testing, refer to the documentation in API overview and the step-by-step guide on making your first API call in Make your first API call.
  • All user rewards belonging to the transaction are reverse-redeemed together. If any one of them is not in the REDEEMED state, the entire request is rejected and none of them change state.
  • A successful reverse-redeem also triggers a rewardRedemptionReversed event notification, if configured. See Supported Events.

Example request

curl --location --request POST 'https://eu.api.capillarytech.com/api_gateway/rewards/core/v1/user/reward/reverse-redeem?username={tillusername}' \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Basic <token>' \
  --data '{
    "txnId": 9876543210,
    "redemptionReversedEventDateTime": "2026-05-13T09:32:11.000Z",
    "redemptionReversedBy": "BRAND_OPERATOR",
    "redemptionReversalReason": "INCORRECT_REDEMPTION"
  }'

Prerequisites

  • Authentication: Basic or OAuth authentication.
  • The REVERSE_REDEEM_ENABLE brand configuration flag must be set to true for the org. It is false by default and is managed through the brand configuration API.
  • The reward transaction must be in the REDEEMED state.

Request query parameters

FieldTypeRequiredDescription
usernamestringOptionalThe unique name of the store(till). If not provided, the store is derived from the authorisation used within the API.

Request body parameters

FieldTypeRequiredDescription
txnIdintegerRequiredThe issuance transaction ID to reverse-redeem. Use the transactionId value returned in the Issue Reward response.
redemptionReversedEventDateTimestringOptionalThe date and time at which the reversal happened at the source, in ISO 8601 format (YYYY-MM-DDTHH:MM:SSZ). Defaults to the processing time if not provided.
redemptionReversedBystringOptionalIdentifier of the actor who initiated the reversal, for example BRAND_OPERATOR. Stored against the reversal record for audit.
redemptionReversalReasonstringOptionalReason for reversing the redemption, for example INCORRECT_REDEMPTION. Stored against the reversal record for audit.

API Quick Reference

POST /api_gateway/rewards/core/v1/user/reward/reverse-redeem
   ├─ Request
   │   ├─ txnId (integer)
   │   ├─ redemptionReversedEventDateTime (string)
   │   ├─ redemptionReversedBy (string)
   │   └─ redemptionReversalReason (string)
   └─ Response
       ├─ status
       │   ├─ success (boolean)
       │   ├─ code (integer)
       │   └─ message (string)
       ├─ txnId (integer)
       ├─ state (string)
       └─ userRewardCount (integer)

Example response

{
  "status": {
    "success": true,
    "code": 200,
    "message": "Reward redemption reversed successfully"
  },
  "txnId": 9876543210,
  "state": "ISSUED",
  "userRewardCount": 1
}

Response parameters

FieldTypeDescription
statusobjectObject containing the outcome of the request.
.successbooleanIndicates whether the reverse-redeem succeeded.
.codeintegerStatus code for the outcome. 200 indicates success; other values indicate the failure reason. See API-specific error codes.
.messagestringHuman-readable description of the outcome.
txnIdintegerTransaction ID that was reverse-redeemed, echoed from the request.
statestringResulting state of the transaction's user rewards. Returned as ISSUED only when the reverse-redeem succeeds.
userRewardCountintegerNumber of user rewards transitioned to ISSUED for the transaction. Returned only when the reverse-redeem succeeds.

Error codes

CodeSymbolic nameMessageWhen it occurs
200REWARD_REVERSE_REDEEMED_OKReward redemption reversed successfullyThe transaction was reverse-redeemed and its rewards moved back to ISSUED.
400INVALID_REQUESTInvalid date format: <value>redemptionReversedEventDateTime was provided but is not a valid ISO 8601 date-time.
13002REVERSE_REDEEM_FEATURE_NOT_ENABLEDReverse-redeem feature is not enabled for this brandThe REVERSE_REDEEM_ENABLE flag is false for the org.
13007REVERSE_REDEEM_INVALID_STATETransaction <txnId> is in state <current_state> but for reverse-redeem the state should be in REDEEMEDOne or more user rewards in the transaction are not in the REDEEMED state. The message reports the actual current state (for example, ISSUED or CANCELLED).
10007TRANSACTION_NOT_FOUNDTransaction not foundNo transaction exists for the provided txnId.
10008USER_REWARD_NOT_FOUNDUser reward not foundThe transaction exists but has no associated user rewards.

Query Params
string

Store identifier used for gateway authentication.

Body Params
int64
required

Transaction ID of the issuance transaction to reverse-redeem.

string

Source event date-time in ISO 8601 format. Defaults to the processing time.

string

Actor who initiated the reversal.

string

Reason for reversing the redemption.

Headers
string
Response

Language
Credentials
Basic
base64
:
URL
LoadingLoading…
Response
Click Try It! to start a request and see the response here! Or choose an example:
application/json