Test a customer journey across several endpoints in a single ordered run. For example: sign in, create an order, retrieve it, then check its status.
Every run shares its own isolated database across its steps. Your workspace records are not changed by those database actions. This version supports isolated endpoint journeys. External requests, email and file actions, cache, realtime, background jobs and streaming are unavailable in suite runs. Database-change triggers are not run; test triggered events separately.
Open Test suites in the sidebar and select Create suite.
Give it a name and, optionally, a description.
Add any Run inputs, such as a test customer's email or a sample order quantity.
Optionally add Starting records for an existing table.
Select Add endpoint step and choose an endpoint from this workspace.
Give each step a different alias, such as login or create_order.
Add request inputs, captures and assertions, then Save suite.
Use the arrow buttons to move a step up or down. Later steps can use earlier responses. Reordering steps may mean a reference is no longer available; review references after moving a step. Leave Stop main steps after the first failure enabled to stop at the first failed check.
You can save up to 25 suites in a workspace, with 20 endpoint steps and five cleanup steps per suite. No extra workspace is needed.
Expand Request inputs and authentication to set path parameters, query parameters, headers and the body. The usual variable editor lets you use a fixed value or a reference.
inputs.quantity uses an input supplied for this run.
steps.create_order.body uses the earlier step's response body.
steps.create_order.body.id uses a field inside that body.
captures.order_id uses a named captured response value.
A response also has status, headers and durationMs. Only earlier steps are available to the next step.
A suite calls your endpoints with their normal customer authentication rules. Your Twidget editor login does not sign in a customer or bypass protected endpoints.
For a sign-in journey, put the customer login endpoint first. Under Capture response values, enter a name such as token and the actual response path, for example body.token. In the next protected step, choose Customer bearer token and select the captures.token variable.
Saved bearer authentication must use a reference, not a pasted token. Supply sensitive test values when running the suite rather than saving them as defaults. Captured tokens and response bodies stay in memory during the run and are not saved in its history.
Expand Assertions and select Add assertion. Choose a response path, a comparison and the expected value. Examples include status equals 200, body.order_status equals pending, or durationMs less than 2000.
Each step supports up to ten assertions and five captures. An assertion checks the current response; it does not use the result prefix used by a saved function test.
Use cleanup steps to check how your endpoints remove the synthetic records created during a journey. They are attempted after main steps, including failures or a cancellation request. Twidget also removes the run’s isolated database after the worker has stopped.
Only one suite can run at a time. A run is bounded to two minutes, with time reserved for cleanup. Choose Test on a saved suite, enter its run inputs and select Run suite. Unsaved edits must be saved or discarded first.
The results show step status, response status, duration and assertion outcomes, plus separate main-step and cleanup status. Isolated database cleanup: Confirmed means the temporary database has been removed. Review interrupted runs and incomplete cleanup before trying the journey again.
Choose Load older runs under Previous runs to see earlier results. Changing the selected suite or workspace starts a new history list.
Previous runs keep the outcome, not customer tokens, captures, response bodies or full headers.
Changes
In Twidget, every modification you make in our no-code builder is meticulously documented and stored as a change. Whether you are creating an input or editing a command, each action is captured in the platform. Important: Please note changes will not go live until they are published. Viewing Changes...
Variables
Variables are essential building blocks in Twidget that allow you to store and manipulate data dynamically within your no-code applications. They enable you to create flexible and interactive applications by holding values that can be changed and referenced throughout your workflow. Creating Variabl...
Reusable Middleware
Middleware is a reusable workflow that runs before or after an endpoint, function or event. Build it once, then apply it wherever you need the same input checks, response formatting or logging. Create middleware. Open Middleware from the sidebar and choose Create Middleware. Give it a clear name, su...
Data Types
Twidget supports six main data types to facilitate interactions within the platform. These data types are essential for defining inputs, outputs, and table fields, helping users understand the nature of the data being handled. The available data types in Twidget are as follows: Text. - Description: ...
Safer Releases
Move a reviewed set of published workflows from a Dev workspace to a Prod workspace. Releases let you review the changes together, keep a release history and review a rollback if you need to restore the previous workflows. Prepare your workspaces. Use two existing workspaces in the same organization...
