Build and Test Your First API
Build and test your first API in Twidget. Create a Tasks table, read its data and return a response, with each save and test shown step by step.
Watch tutorial (3:51)
Build and test your first API in Twidget. Create a Tasks table, read its data and return a response, with each save and test shown step by step.
Watch tutorial (3:51)
Trace a workflow execution to see which commands ran, how long they took and where a workflow failed.
Watch tutorial (3:25)
Use breakpoints and stepping to follow a workflow one command at a time, including stepping into a called function and returning to the caller.
Watch tutorial (4:58)
Save and run a multi-step test suite with starting records, run inputs, captured response values, assertions and cleanup. Verify that workspace records remain unchanged.
Watch tutorial (8:17)
Save inputs and assertions, then run tests for functions and endpoints.
Recorded with an earlier Twidget interface. Names, control locations and available options may differ; use the linked documentation for current guidance.
Watch tutorial (3:31)To pause an isolated test and move through commands, see Live debugging.
In Twidget, you can easily test your endpoints and functions directly within our code builder. This guide will walk you through the steps to efficiently test your functions to ensure they meet your requirements.
To start testing, follow these steps:
Open Code Builder:
Click Test:
In the test sidebar, you have the option to define the input values that your function will be tested with:
Input Fields:
Assertions are used to validate the results of your function tests. You can add multiple assertions to ensure thorough testing:
Assertions Section:
Types of Assertions:
Equality: Check if the result equals a specific value.
Comparison: Validate if the result is greater than, less than, etc.
Multiple Assertions: Add multiple conditions to fully test your function's logic.
Test Success: A test will pass only if all the assertions specified are true.
Test Failure: If any assertion is false, the test will fail.
Use execution tracing to see which commands ran, how long they took, and where a run encountered an error.
Open Test for your endpoint, function or event.
Select Trace execution before starting the next run.
Optionally select Include variable values when you need to inspect available recorded variable changes.
Run the test and open its results.
Review the Execution trace list. Select a step to open its details.

Tracing is optional. Turning it on applies to the next run; it does not add details to an earlier result. Your test's ordinary output, errors and assertions remain available.
Use Search trace to find a command or error, or select Only errors to narrow the list. Nested commands and loop iterations help you follow repeated work.
Select a recorded step to see its status, duration, start time, location and any captured error or variable values. Previous and Next move between recorded steps in the current filtered list. Reviewing these steps does not run the commands again.

When a step matches a command in your current workflow, Show current command takes you to that command. If it cannot be matched, the recorded details remain available. The current command may have changed since the test was run.
A step marked Handled error encountered an error that the workflow handled while the overall run completed successfully. Review the step and the final output to check that your recovery behaved as intended.

For a Database Transaction, a child command marked Success only shows that the child finished its work. If a transaction failed or was cancelled, its successful child steps are shown as Executed, and its details explain that commit was not confirmed. This does not prove that changes were saved or rolled back. See Save Changes Together.
If the run times out, close any error dialog to review an available partial trace of the steps captured before it stopped. The timeout warning remains visible, and the run did not complete. A partial trace may not include every step or its final outcome.

Leave Include variable values off unless you need those details. Common sensitive fields, such as passwords, tokens and keys, are hidden; large values are shortened. Some values are intentionally omitted after sensitive operations or when their origin cannot be safely confirmed. Use sample data and review captured values before sharing a trace.
A trace captures up to 500 steps for a test, with additional limits on the total capture size. When a limit is reached, the result explains that steps were omitted. Missing or shortened details are not evidence that a command did not run. Narrow the test case and run it again if you need a more focused result.

Twidget allows you to save your tests for future use and manage multiple tests efficiently:
Save Tests: After configuring your test inputs and assertions, you can save the test for future runs.
Create Multiple Tests: You can create as many tests as needed to cover different scenarios.
Run Tests Individually or All at Once:
Individual Run: Execute a single test to check specific functionality.
Run All: Execute all the tests at once to quickly verify multiple conditions.
On narrow sidebars, each saved test shows its name above one row of actions. Use the play, debug, rename, duplicate or delete buttons; hover or focus a button to read its label. Long test names wrap inside the card.

By following these guidelines, you can ensure your functions and endpoints perform as expected in various scenarios.
Working on smaller screens
Twidget adapts its navigation, lists and editing panels to phones, tablets and smaller laptop windows. You can use the same workspace and saved workflows across these views. Open your workspace tools. On a phone, use the menu button at the top to open workspace navigation. Choose a tool from Build, ...
Command Output
Some commands in Twidget return outputs, which are essential for dynamic and conditional logic within your workflows. These outputs are displayed next to the command and are prefixed with an "as" to indicate the variable name. Using Output Variables. Once a command returns an output, you can use the...
Test suites
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 is...
Dynamic variables in JSON and text
Build JSON bodies and messages using values from your workflow. The Insert variable picker lets you choose inputs, earlier command results, nested object fields and list items without typing their references. Choose a nested field or list item. 1. Open a command value or function output and choose J...
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...