Overview

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.

Validation Quickstart

SlashApi allows you to create custom validation for your API from SlashApi dashboard. Follow this step to create custom validation.

  1. Select the API that you want to validate the input
  2. Choose the secure endpoint icon
  3. Select Request Validations tab

Writing The Validation Logic

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)

Custom Validation Form

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.

Example Error Response

{
    "message": "The given data was invalid.",
    "errors": {
        "data.username": [
            "The username field is required."
        ],
        "data.email": [
            "The email has already been taken."
        ]
    }
}

Available Validation Rules

Below is a list of all available validation rules and their function:

accepted

The field under validation must be yes, on, 1, or true. This is useful for validating "Terms of Service" acceptance or similar fields.

active_url

The field under validation must have a valid A or AAAA record.

after:date

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

alpha

The field under validation must be entirely alphabetic characters.

alpha_dash

The field under validation may have alpha-numeric characters, as well as dashes and underscores.

alpha_num

The field under validation must be entirely alpha-numeric characters.

array

The field under validation must be an array.

before:date

The field under validation must be a value preceding the given date.

between:min,max

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.

boolean

The field under validation must be able to be cast as a boolean. Accepted input are true, false, 1, 0, "1", and "0".

confirmed

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.

date

The field under validation must be a valid date.

date_equals:date

The field under validation must be equal to the given date.

date_format:format

The field under validation must match the given format. You should use either date or date_format when validating a field, not both.

different:field

The field under validation must have a different value than field.

distinct

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

email

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:

  • rfc: RFCValidation
  • strict: NoRFCWarningsValidation
  • dns: DNSCheckValidation
  • spoof: SpoofCheckValidation
  • filter: FilterEmailValidation

ends_with

The field under validation must end with one of the given values.

ends_with:foo,bar,...

exists

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.

file

The field under validation must be a successfully uploaded file.

filled

The field under validation must not be empty when it is present.

gt:field

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.

gte:field

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.

image

The file under validation must be an image (jpg, jpeg, png, bmp, gif, svg, or webp).

in

The field under validation must be included in the given list of values.

in:foo,bar,...

integer

The field under validation must be an integer.

ip

The field under validation must be an IP address.

ipv4

The field under validation must be an IPv4 address.

ipv6

The field under validation must be an IPv6 address.

json

The field under validation must be a valid JSON string.

lt:field

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.

lte:field

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.

max:value

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.

min:value

The field under validation must have a minimum value. Strings, numerics, arrays, and files are evaluated in the same fashion as the size rule.

mimetypes

The file under validation must match one of the given MIME types:

mimetypes:video/avi,video/mpeg,video/quicktime

mimes

The file under validation must have a MIME type corresponding to one of the listed extensions.

mimes:jpg,bmp,png

not_in

The field under validation must not be included in the given list of values.

not_in:foo,bar,...

not_regex:pattern

The field under validation must not match the given regular expression.

not_regex:/^.+$/i

nullable

The field under validation may be null.

numeric

The field under validation must be numeric.

present

The field under validation must be present in the input data but can be empty.

regex:pattern

The field under validation must match the given regular expression.

regex:/^.+@.+$/i

required

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 value is null.
  • The value is an empty string.
  • The value is an empty array or empty Countable object.
  • The value is an uploaded file with no path.

required_if

The field under validation must be present and not empty if the anotherfield field is equal to any value.

required_if:anotherfield,value,...

required_unless

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,...

required_with

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,...

required_with_all

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,...

required_without

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,...

required_without_all

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,...

same

The given field must match the field under validation.

same:field

size

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

sometimes

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.

starts_with

The field under validation must start with one of the given values.

starts_with:foo,bar,...

string

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

timezone

The field under validation must be a valid timezone identifier.

unique

The field under validation must not exist within the given database table. This validation only work for Database API.

unique:table,column

url

The field under validation must be a valid URL.

uuid

The field under validation must be a valid RFC 4122 (version 1, 3, 4, or 5) universally unique identifier (UUID).