For example:
In the web, Variable A have choices:
1
2
3
4
But API include Variable A with value: 6
This should be block.

Currently variable value checking is not subject to permission check as otherwise the permission system can be very complicated (considering different configurations have different variable types/values). You may consider checking if variable value is expected at start of your build, and fail it upon an unexpected value.

I know but we have to do that, because we need to fragment user permission with each of choices variable values. Permissions system are not enough to use.

Do you mean different user is allowed to trigger build with different set of variable values? Making this part of general permission schema is somewhat difficult considering different configurations having different variables and values. So I'd suggest to do it in your build instead: you can even check in your build against triggering user name to determine if the variable values specified are permitted.

Yes, Thank you. I think that I'll check this permission in Re-queue Script.

When I return a through exception, API response prints whole pre-queue script in the master log, and in the user's return value.

If I return false, request was rejected. But status code is 200 ok. Because 200 should be build started okay. => We don't detect although this request was rejected.
Please help us.

You may check it in the pre-build script or add a groovy scripting step as the first step of the build.

Yes, I can check and block this problem but how can it return reject status code (403,....) not 200 OK in groovy script exclude error message? Have you any idea?

We will improve pre-queue script so that it can return user defined status code and error message. Please watch below issue:

Thank you! I am updating the latest version to apply this change.

No problem. Just return an integer number to indicate http status code in pre-queue script, or return 200 to accept the request

@robinshen Excuse me, After integrate with https://track.pmease.com/browse/QB-3559 "Improve pre-queue script to return status code and status as necessary", It ran well with status code controler. But we are not able to control reject reason of requester.
This improvement only supporting control status response, not including flexible reason. Please help us improve both status code and reason of response under only a returning;

Filed as below improvement request: