Stamp Redemption API (v2)
The Stamp Redemption API marks a reward (e.g., free drink, discount) as redeemed once a customer completes all required stamps.
After redemption, the stamp cannot be used again, and a new stamp must be issued to start the next cycle.
This API is typically used in systems that provide rewards based on visit or purchase history.
This API is available on the Personal plan or higher.
/api/stamp/v2/redeem
{
"stampIdx": 394,
"onsiteToken": "QsBkV0ryiCkxiV4KUNJBSWQcR8MzSlvez4ntLh2Tt2M",
"processStoreIdx": 22
}
Request Parameters
- stampIdx integer required
- Stamp IDX.
- onsiteToken string
-
Short-lived exchange token for on-site processing. v2 does not accept the plaintext
password (
onsitePwd).
When the stamp hasonsiteYn = Y, send theonsiteTokenreturned by the Validate API as is.
Idempotency-Keyis required for requests that use a token. A retry with the same key replays the original result; using the same token with a different key is rejected with400(error code1228).
If a processing store was given at validation, this request must use the same store. A token issued without a store cannot be used with a store either. - 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.
Where Does Stamp Redemption Fit?
This is the final stage of the stamp system.
- Verify that stamp accumulation is complete
- Process reward fulfillment
- Mark the stamp as redeemed
It is not just a state change, but the step that finalizes the campaign outcome.
Completion Point of the Stamp Lifecycle
This API represents the final step in the stamp lifecycle.
From the user’s perspective, it’s the moment they receive a reward after completing the stamps. From a developer’s perspective, it marks the end of one cycle and the start of the next.
After calling the Redemption API, issuing a new stamp immediately with the Create API helps maintain continuous user engagement.
Full Stamp Lifecycle
Create→ Issue a stamp to the userAdd Stamp→ Accumulate stamps on visits or purchasesValidate→ Check if all stamps are completedRedeem→ Process reward redemptionCreate→ Start a new cycle with a new stamp
On-site verification token (onsiteToken)
v2 does not accept the on-site password in plaintext (onsitePwd).
Send the onsiteToken returned by the Validate API unchanged.
Sending onsitePwd by itself or together with onsiteToken is rejected with
400 (error code 1227).
Idempotency-Key is required for requests that use a token.
Retrying with the same Idempotency-Key returns the original processing result.
Reusing the same token with a different Idempotency-Key is rejected with
400 (error code 1228).
The store used for validation must match the store where the operation is processed.
If processStoreIdx was specified during validation, this request must use the same store.
A token validated without a store cannot later be associated with one.
Expired, tampered, already consumed, or incorrectly bound tokens all return 1228.
These causes are intentionally not distinguished because doing so could allow a third party to probe internal state using another token.
No token is required for resources that do not use on-site verification (onsiteYn = N).
v1 continues to accept onsitePwd in plaintext.
Post-Redemption Automation Flow
You can trigger automated workflows when a reward is marked as redeemed.
- Call the Coupon Create API to instantly issue a reward coupon
- Immediately create a new stamp to start the next accumulation cycle
- Use webhooks to notify users that redemption is complete
Automating this flow enables a complete reward lifecycle—from fulfillment to re-engagement—without manual intervention.
Operational Considerations
This API is not just a feature—it is the point where business outcomes are finalized.
- Incorrect handling can lead to duplicate rewards
- Potential user claims or disputes
- Increased campaign costs
Always enforce validate → redeem sequencing, server-side transactional control, and audit logging.