Setting up Backend Validations
Backend validations let you verify what happens in the backend while the AI agent interacts with your app. If the UI triggers an API call or changes data in the backend, you can verify that the backend response matches what you expect. This keeps your tests grounded in real application behavior, not just what appears on the screen.
Validations can be used in two ways:
Saved as a Validation
Create it once and reuse it across tasks and test suites.
Used as a Prompt Action
Call a validation directly inside a natural language prompt by typing
@. The validation appears as a selectable action and runs exactly where you place it in the prompt. Keep in mind, that the order matters.
Navigation
In the top-left navigation, after Suites, you will see Validations.
Inside this section, you will find two tabs:
Connections
Validations
You can also switch between environments (dev, stage, prod).
Step 1: Create a Backend Connection
A connection is the setup Quash uses to talk to your backend. It defines where your backend lives and how to authenticate with it. This includes the base URL, the authentication method and any headers needed to make a valid request. Once a connection is created, all validations under it can use the same configuration. Think of it as the foundation: without a connection, Quash has no way to reach your API or database. A single connection can have multiple validations.
Click Create your first connection.
Enter a connection name.
Connection type is API by default. (Database support coming soon.)
Configure your API:
Base URL
Authentication type:
No Auth: Use this for public endpoints that do not require authentication.
Bearer Token: Sends
Authorization: Bearer <token>with every request.API Key: Provide a header name and key value for APIs that expect authentication through custom headers.
Custom Header: Add any custom header needed for non-standard or multi-header authentication.
Save the connection.
Step 2: Create a Validation
A validation is a specific backend check that runs during a test. It defines the exact API you want to call, the request details, and the response you expect to receive. While the use case is confirming that UI actions match backend state, the validation itself is a technical definition of one call and its expected output. This can include status codes, JSON fields, regex patterns, or extracted variables. Multiple validations can be created under a single connection.
Open the Validations tab and click Add Validation or Create Validation.
A validation setup has four steps:
1. Basic Info
Validation name: Give it a clear, descriptive title.
Description: Explain what this validation checks and why it matters. This is optional.
Select backend connection: Choose the connection where this validation will run.
Select Continue.
2. HTTP Request
Select HTTP method:
GET – Fetches data from the server without modifying anything.
POST – Sends new data to the server, typically used to create resources.
PUT – Replaces an existing resource with new data.
PATCH – Updates part of an existing resource.
DELETE – Removes a resource from the server.
Add the endpoint path: Enter the relative path of the API route you want to call (for example:
/products,/users/123/orders). The base URL and endpoint path combine to form the full request URL, which updates automatically.Add query parameters: Use these to pass key-value pairs in the URL for filters, pagination, or search. You can add multiple parameters if needed and this is optional.
Add custom headers: Add extra headers required by this specific endpoint, such as content type or feature flags. These apply only to this validation, not the whole connection. This is optional.
3. Response Validation
Configure what you expect from the backend.
Status codes: Choose from defaults (200, 201, 202, 204, 400, 404) or enter your own.
Request timeout: Default is set to 5000 ms.
Retry attempts and retry backoff: Configure how many times the request should retry and the delay between retries.
Expected response data: This is optional and supports partial matching.
JSON Path assertions: To check specific fields inside the JSON response.
Regex assertions: Check the response against specific text patterns.
Extract variables: Capture values from the response to store as variables.
Mark as required: If enabled, the task fails when this validation fails.
4. Advanced Options
Enable prompt action: To make this validation callable inside prompts using
@.Action slug: A unique identifier that lets the AI call this validation inside prompts. Example slugs:
@get_products,@fetch_user_profileDescription: a short description for the AI, this is also optional
Parameters: To define input parameters for dynamic use.
Then click Save Validation.
Using Validations During Execution
There are two ways to use validations in tasks:
1. Inside the Prompt
Type @ in your task prompt.
Your available validations appear.
Select one, and it will run at that exact point in the prompt sequence.
Example prompt: Open the app and go to the Products screen. Validate that the items shown match what you expect, then run @get_products to confirm the backend returns the correct product list.
2. From Task Settings
Open a task and go to Settings.
You can:
Add one or more validations
Choose when they run: before execution, after execution, or both
Mark them as required or optional
Add variables: They can be added in a
key=valueformat.
Last updated