Block client-side SendReward calls by adding an API version blocklist entry to your Rewards App.
This step is optional but highly recommended for apps with high-value rewards or when you need complete control over reward issuance.
Enabling the blocklist rejects client SDK reward calls for this app. You can revert at any time by deleting the blocklist entry.
Configuration
Client identifier (use “developer-dashboard” )
Bearer token for authentication Format: Bearer {JWT_TOKEN}
Path Parameters
Body Parameters
API version to blocklist Use 1 to block client SDK calls (to block Send Reward v1)
The API route to blocklist Use “/rewards/limited-achievement/reward” to block client reward sending
{
"success" : true ,
"message" : "API version blocklist created successfully." ,
"data" : {
"id" : "e2fbc21e-b524-4304-aa55-b20941ede9f6" ,
"rewardsAppId" : "b28e0306-2c06-4092-8d56-a1623d6b97fb" ,
"version" : 1 ,
"apiRoute" : "/rewards/limited-achievement/reward" ,
"createdAt" : "2025-10-29T14:06:50.321Z"
}
}
400 - Bad Request
401 - Unauthorized
403 - Forbidden
409 - Conflict
500 - Server Error
{
"success" : false ,
"message" : "Invalid parameters"
}
Response Fields
Field Type Description
successboolean Whether the request was successful messagestring Description of the result dataobject Contains blocklist entry details idstring Unique identifier for this blocklist entry rewardsAppIdstring Your Rewards App ID versionnumber API version that is blocklisted (Send Reward v1) apiRoutestring The API route that is blocklisted createdAtstring ISO 8601 timestamp of when the entry was created
Response Status Codes
Code Description
200Blocklist entry created successfully 400Bad request - invalid parameters 401Unauthorized - authentication required 403Forbidden - developer does not own this app 409Conflict - blocklist entry already exists 500Internal server error
What Happens After Restriction?
After applying this blocklist:
Client SDK Blocked Client SDK calls to send rewards will be rejected
Backend Server Active Server calls with API key will continue to work
Client SDK Behavior
When a client tries to send rewards via v1 after the blocklist is applied:
Error: This endpoint requires API key authentication. Please use the API key endpoint instead.
Server Behavior
Your backend server can continue sending rewards normally using the v2 endpoint with your API key.
Code Examples
const rewardsAppId = 'YOUR_REWARDS_APP_ID' ;
const jwtToken = 'YOUR_JWT_TOKEN' ;
async function restrictClientRewards ( rewardsAppId ) {
const response = await fetch (
`https://api.zbdpay.com/api/v1/rewards/app/ ${ rewardsAppId } /api-version-blocklist` ,
{
method: 'POST' ,
headers: {
'z-client' : 'developer-dashboard' ,
'Authorization' : `Bearer ${ jwtToken } ` ,
'Content-Type' : 'application/json'
},
body: JSON . stringify ({
version: 1 ,
apiRoute: '/rewards/limited-achievement/reward'
})
}
);
const data = await response . json ();
if ( data . success ) {
console . log ( 'Client rewards restricted successfully!' );
console . log ( `Blocklist entry ID: ${ data . data . id } ` );
return data . data ;
} else {
throw new Error ( `Failed: ${ data . message } ` );
}
}
// Apply restriction
await restrictClientRewards ( 'b28e0306-2c06-4092-8d56-a1623d6b97fb' );
You only need to create a single block list entry with version 1 to disable client-side rewards. To re-enable client rewards, simply delete that block list entry.
You can remove the blocklist entry at any time to re-enable client-side reward sending by deleting the blocklist entry.
What’s Next?
You’ve now restricted client-side reward sending and enforced backend-only control.
Next, continue managing and securing your Rewards App: