Skip to main content
Scripts are reusable code blocks stored in the Library. Reference them from Script steps in any test to run real code: set up state, generate credentials, call your APIs, or compute values your tests need at runtime. Python, JavaScript, TypeScript, and Bash are all supported.

​
What Scripts Are For

  • Mutate backend state: seed test data, create users, reset account balances, enqueue jobs, open/close feature toggles
  • Generate credentials: mint a fresh test user, call your auth service for a short-lived token, rotate API keys per run
  • Compute dynamic values: unique emails (test+{{timestamp}}@example.com), hash challenges, signed URLs, HMAC signatures
  • Call external services: hit your APIs, a third-party sandbox, a CI system, or a notification channel mid-test
  • Parse or transform data: pull a value out of a response, decode a JWT, compute a checksum for validation
Scripts bridge the gap between what the AI agent does on the device and the rest of your infrastructure.

​
Creating a Script

  1. Go to Library > Scripts tab
  2. Click New script
  3. Name it, pick a language (Python, JavaScript, TypeScript, or Bash), and write your code
  4. Save. The script is now available org-wide.
Changes to a script propagate to every test that references it. The editor warns you before saving if other tests are using it.

​
Using a Script in a Test

In the test editor, add a Script step and select a saved script from the dropdown. The script runs in a sandboxed environment when the test hits that step.

​
Saving Output to a Variable

Set variable_name on the Script step and the script’s stdout is stored in that variable. Reference it in later steps: 
Script step:
  script: generate_test_user
  variable_name: user_email

Next instruction:
  "Type {{user_email}} into the email field"
Use this to chain steps that depend on values generated at runtime. Think signup flows, one-time codes, computed IDs.

​
Inline vs Library Scripts

You can also write ad-hoc code directly in a Script step without saving it to the Library. Use inline scripts for test-specific logic, and save to the Library when you want to reuse the same code across multiple tests.