Authorized/Early Request Validator 

Use the Authorized and Early Request Validator API policies to perform generic validation steps on requests and return customized responses. You can use both policies in tandem or just one. For example, if a Task requires a particular HTTP header in a particular format, that can be validated with one of these API policies before incurring the cost of executing a Pipeline. 

Policy Execution Order

Although both policies have the same configuration options, the difference between the two API policies is the order of execution:

  • The Early Request Validator policy executes before authentication.
  • The Authorized Request Validator policy executes after authorization.

Expression Enabled Fields in API Policies

All expression enabled fields take expressions from the SnapLogic Expression Language and the API Policy Manager functions.

Parameter NameDescriptionDefault ValueExample
LabelRequired. The name for the API policy.

Authorized Request Validator

Early Request Validator



When this policy should be appliedAn expression enabled field that determines the condition to be fulfilled for the API policy to execute.Truerequest.method == "POST"
Validation ChecksA table of checks to perform on the request.N/AN/A

An expression that should return true if the request should be aborted.

You cannot use request.remoteUser or request.isUserInRole() functions with the Early Request Validator policy, which is applied before authentication. Instead, use the Authorized Request Validator policy and set the Condition parameter to the Boolean returned by these functions.

StatusThe HTTP Status code to use in the response.400 (Bad Request)413 (Request Entity Too Large)
ResponseThe response to send to the client.N/A
  • To return a custom HTML page:

'Content-Type': 'text/html',
entity: 'Bad request, see <ahref="">here</a> for more details'
  • To return a Location header for a 3xx status code:


    Location: ''

StatusIndicates whether the API policy is enabled or disabled. EnabledDisabled

These policies allow a great deal of flexibility in determining how a request is handled before it reaches a Pipeline; ss such, you must carefully consider the request flow of your API when configuring this policy.  


Use this policy to ensure a request is valid before the Triggered Task is executed by applying these settings in the dialog

  • Condition: !(request.uri.query matches { id: /\d+/ })
  • Status: 400
  • Response: Try Again

Where the Response expects an ID query parameter that is a number.