Install the Vivoldi app from Google Play to make it even more convenient.

Stamp Remove API (v2)

The Stamp Remove API decrements the stamp count of an existing record by one.

It is not part of the standard accumulation flow, but is used for corrective scenarios such as fixing incorrect accruals, updating campaign rules, or handling user claims.
The stamp count will never drop below zero.

This API is available on the Personal plan or higher.

PUT

/api/stamp/v2/remove 

{
    "stampIdx": 394,
    "stamps": 1,
    "processStoreIdx": 22
}

Request Parameters

stampIdx integer required
Stamp IDX.
stamps integer
Number of stamps to add (or remove). Defaults to 1 and must be greater than 0.
Amounts exceeding the card maximum or falling below zero are clamped by the server. If the actual change is 0, no history entry or webhook is created.
processStoreIdx integer
IDX of the store where this request is actually processed. When sent, the server verifies organization ownership, active status and permissions before recording it in the processing history.
The processing branch is not taken from the request; the server derives it from this store. This is different from the issuing store (storeIdx). 
{
    "code": 0,
    "message": "",
    "result": null
}

Response Parameters

code integer
Response code: 0 = Success, other values = Error
message string
Response message. If the response code is not 0, an error message is returned.
result null

Numeric parameter validation

If a numeric parameter receives a non-numeric value, or a number beyond the range the server can handle, the request is rejected immediately with 400 (error code 653).

In that case no stamp data or earning history changes at all, and no event record or Webhook delivery is produced. A failed response means nothing was saved.

Specifying the processing store

Parameter Meaning Description
processStoreIdx Processing store The store where this request is actually processed. Optional. When sent, the server verifies organization ownership, active status and permissions before recording it in the processing history.

The processing branch is not accepted from the request. The server derives and records it from the store you specify.

When the usable scope is BRANCH, the request is processed only if the branch of the verified processing store matches the usable branch, or if you authenticate with that branch's on-site password. Without either, it is rejected.

Parameters that cannot be used — branchIdx (issuing branch), storeIdx (issuing store), useScope (usable scope) and useBranchIdx (usable branch) are already-stored issuance policy and cannot be changed through this API. Sending them returns 400 (error code 1227).

Idempotency-Key

To retry safely when a response is lost to a network error, send a value that is unique per request in the Idempotency-Key header. You can also send it as requestId in the body; if both are sent with different values, the request is rejected. The allowed format is 8–64 characters of letters, digits and . _ : -.

Sending the same request again with the same key returns the original result without processing it again. Nothing is processed twice and webhooks are not sent again.

Use the same key only for retries of the same logical operation. Always use a new key for a different operation. Using the same key with different request content or for a different operation may be rejected with 409.

When to Use Stamp Deduction

This API is not intended for frequent use. It is an administrative tool designed to resolve data issues.
It is typically used in the following scenarios:

  • Duplicate event processing results in stamps being added twice
  • System errors cause incorrect stamp increases
  • Campaign rule changes require adjustment of existing data
  • Incorrect accruals need to be rolled back

Leaving incorrect data uncorrected can increase reward costs and reduce campaign trust.
The Deduction API provides a direct way to fix these issues immediately.

Relationship with the Add Stamp API

These two APIs operate in opposite directions, but their roles are clearly defined.

  1. Add Stamp → Records user actions in the normal campaign flow
  2. Remove Stamp → Adjusts or rolls back data in exceptional scenarios

In every scenario where the Add Stamp API is used, cancellation and failure cases should also be designed.
Integrating the Remove Stamp API into those flows is a best practice for building a reliable stamp system.

Operational Considerations

The Stamp Deduction API is not used frequently. It is a critical administrative API for resolving data issues.

  • Uncorrected data reduces campaign trust
  • Over-accumulation increases reward costs
  • Negative impact on user experience

Use this API with audit logging and strict admin-level access control.

Things to consider

  • Stamp count never goes below 0. Check stamps via the Validation API before deducting
  • Repeated calls can cause unintended excessive deductions
  • Do not call this API directly from the client. Enforce validation and limits on the server
  • Record deduction history and protect it with proper admin access control