Before submitting data to the API endpoint, it is important to ensure all required form controls are filled out in the correct format. You can validate the input on the client-side, However, client-side validation should not be considered an exhaustive security measure. Client-side validation is too easy to bypass, so malicious users can still easily send bad data to your API endpoint. Your API should always perform security checks on any submitted data on the server-side.
Looking to the case above, SlashApi provides a way to validate input coming to your API. This custom validation will be useful when you build an API with dynamic fields like Database API (PostgreSQL, MySQL, MongoDB), Google Sheets, Airtable, etc.
SlashApi includes a wide variety of convenient validation rules that you may apply to data, even providing the ability to validate if values are unique in a given database table.
SlashApi allows you to create custom validation for your API from SlashApi dashboard. Follow this step to create custom validation.
To define multiple validation rules, you need to separate each rule in vertical bar |. The example below show you how to validate a field with required and email format.
required|email
On the SlashApi dashboard, to create custom validations you need to specify the request method and resource (in database it means table, in google sheets it means sheet name)
Request Method
Your custom validation will be executed if the request method you send to the API is equals with the request method you set in the Custom Validations form. For example, when you choose request method POST, the validation will executed when you send POST request to your API endpoint.
On SlashApi, we use POST request to insert new data to the data source, and PUT or PATCH method used to update data in the data source.
If the validation rules pass, your API will executing normally and you will receive the response as usual, if validation fails, a JSON response containing the validation error messages will be returned.
{
"message": "The given data was invalid.",
"errors": {
"data.username": [
"The username field is required."
],
"data.email": [
"The email has already been taken."
]
}
}
Below is a list of all available validation rules and their function:
The field under validation must be yes, on, 1, or true. This is useful for validating "Terms of Service" acceptance or similar fields.
The field under validation must have a valid A or AAAA record.
The field under validation must be a value after a given date. For example, if you want to validate an input date must be a date after tomorrow, you can write the rule like below:
after:tomorrow
Instead of passing a date string, you may specify another field to compare against the date. For example, you want to validate end_date must be after start_date value.
after:start_date
The field under validation must be entirely alphabetic characters.
The field under validation may have alpha-numeric characters, as well as dashes and underscores.
The field under validation must be entirely alpha-numeric characters.
The field under validation must be an array.
The field under validation must be a value preceding the given date.
The field under validation must have a size between the given min and max. Strings, numerics, arrays, and files are evaluated in the same fashion as the size rule.
The field under validation must be able to be cast as a boolean. Accepted input are true, false, 1, 0, "1", and "0".
The field under validation must have a matching field of {field}_confirmation. For example, if the field under validation is password, a matching password_confirmation field must be present in the input.
The field under validation must be a valid date.
The field under validation must be equal to the given date.
The field under validation must match the given format. You should use either date or date_format when validating a field, not both.
The field under validation must have a different value than field.
When validating arrays, the field under validation must not have any duplicate values:
You may add ignore_case to the validation rule's arguments to make the rule ignore capitalization differences:
distinct:ignore_case
The field under validation must be formatted as an email address. By default, the RFC Validation validator is applied, but you can apply other validation styles as well:
email:rfs,dns
The example above will apply the RFC Validation and DNS Check Validation validations. Here's a full list of validation styles you can apply:
The field under validation must end with one of the given values.
ends_with:foo,bar,...
The field under validation must exist in a given database table. This rule only work for Database API.
Basic usage of exists Rule
exists:states
If you put the validation above on state field, the rule will validate that the states database table contains a record with a state column value matching the request's state attribute value.
Specifying A Custom Column Name
You may explicitly specify the database column name that should be used by the validation rule by placing it after the database table name:
exists:offices,id
If you put the validation on office_id field, the rule will validate that the offices database table contains a record with id column value matching the request's office_id attribute value.
The field under validation must be a successfully uploaded file.
The field under validation must not be empty when it is present.
The field under validation must be greater than the given field. The two fields must be of the same type. Strings, numerics, arrays, and files are evaluated using the same conventions as the size rule.
The field under validation must be greater than or equal to the given field. The two fields must be of the same type. Strings, numerics, arrays, and files are evaluated using the same conventions as the size rule.
The file under validation must be an image (jpg, jpeg, png, bmp, gif, svg, or webp).
The field under validation must be included in the given list of values.
in:foo,bar,...
The field under validation must be an integer.
The field under validation must be an IP address.
The field under validation must be an IPv4 address.
The field under validation must be an IPv6 address.
The field under validation must be a valid JSON string.
The field under validation must be less than the given field. The two fields must be of the same type. Strings, numerics, arrays, and files are evaluated using the same conventions as the size rule.
The field under validation must be less than or equal to the given field. The two fields must be of the same type. Strings, numerics, arrays, and files are evaluated using the same conventions as the size rule.
The field under validation must be less than or equal to a maximum value. Strings, numerics, arrays, and files are evaluated in the same fashion as the size rule.
The field under validation must have a minimum value. Strings, numerics, arrays, and files are evaluated in the same fashion as the size rule.
The file under validation must match one of the given MIME types:
mimetypes:video/avi,video/mpeg,video/quicktime
The file under validation must have a MIME type corresponding to one of the listed extensions.
mimes:jpg,bmp,png
The field under validation must not be included in the given list of values.
not_in:foo,bar,...
The field under validation must not match the given regular expression.
not_regex:/^.+$/i
The field under validation may be null.
The field under validation must be numeric.
The field under validation must be present in the input data but can be empty.
The field under validation must match the given regular expression.
regex:/^.+@.+$/i
The field under validation must be present in the input data and not empty. A field is considered "empty" if one of the following conditions are true:
The field under validation must be present and not empty if the anotherfield field is equal to any value.
required_if:anotherfield,value,...
The field under validation must be present and not empty unless the anotherfield field is equal to any value. This also means anotherfield must be present in the request data unless value is null. If value is null (required_unless:name,null), the field under validation will be required unless the comparison field is null or the comparison field is missing from the request data.
required_unless:anotherfield,value,...
The field under validation must be present and not empty only if any of the other specified fields are present and not empty.
required_with:foo,bar,...
The field under validation must be present and not empty only if all of the other specified fields are present and not empty.
required_with_all:foo,bar,...
The field under validation must be present and not empty only when any of the other specified fields are empty or not present.
required_without:foo,bar,...
The field under validation must be present and not empty only when all of the other specified fields are empty or not present.
required_without_all:foo,bar,...
The given field must match the field under validation.
same:field
The field under validation must have a size matching the given value. For string data, value corresponds to the number of characters. For numeric data, value corresponds to a given integer value (the attribute must also have the numeric or integer rule). For an array, size corresponds to the count of the array. For files, size corresponds to the file size in kilobytes.
size:value
Let's look at some examples:
// Validate that a string is exactly 12 characters long...
size:12
// Validate that a provided integer equals 10...
integer|size:10
// Validate that an array has exactly 5 elements...
array|size:5
// Validate that an uploaded file is exactly 512 kilobytes...
file|size:512
In some situations, you may wish to run validation checks against a field only if that field is present in the data being validated. To quickly accomplish this, add the sometimes rule to your rule list:
sometimes|required|email
In the example above, the email field will only be validated if it is present in the data array.
The field under validation must start with one of the given values.
starts_with:foo,bar,...
The field under validation must be a string. If you would like to allow the field to also be null, you should assign the nullable rule to the field. For example:
nullable|string
The field under validation must be a valid timezone identifier.
The field under validation must not exist within the given database table. This validation only work for Database API.
unique:table,column
The field under validation must be a valid URL.
The field under validation must be a valid RFC 4122 (version 1, 3, 4, or 5) universally unique identifier (UUID).