Skip to main content
Use a multi-step API check when availability depends on several requests succeeding together. A token endpoint returning 200 does not prove that a caller can create an invoice and read it back. Write the sequence as a Playwright test that uses the request fixture. Assert the expected response at each step and clean up resources your test creates. Use test accounts and data suitable for repeated execution against the target environment.

​
Prepare your package

Put the test entrypoint and the local files it imports in a ZIP. Paths in the package metadata are relative to the archive root: tests/invoice.spec.ts identifies that file inside the ZIP, not an absolute path on your computer. You need:
  • The ZIP’s SHA-256 digest, as 64 hexadecimal characters
  • The entrypoint path and included file paths
  • An environment ID in the monitor’s workspace
  • Any secret names the package requires and their environment bindings
Do not include credentials in the ZIP. Set sensitive values through your environment’s secret bindings and read them from process.env in the test.

​
Upload and create the monitor

Authenticate with a token that can write monitors in the selected workspace. Set DEVHELM_API_TOKEN, DEVHELM_WORKSPACE_ID, ENVIRONMENT_ID, and PACKAGE_SHA256 before running the examples. PACKAGE_SHA256 must match the exact ZIP bytes you upload.

​
Request an upload URL

API
The response contains putUrl, expiresAt, and requiredHeaders. Upload the ZIP bytes with HTTP PUT to that signed URL before it expires. Send the returned required headers, including Content-Type: application/zip and If-None-Match: *. The signed storage URL authorizes the upload. Do not send your DevHelm API token to it. If the same digest already exists, preserve the existing object; changing the package requires a new digest.

​
Create the monitor

After the upload succeeds, create a MULTI_STEP_API monitor that references the package metadata:
API
The example assumes the ZIP contains one file, tests/invoice.spec.ts. Include every packaged local file in files. If the test requires secrets, also include their names in package.keys and configure the corresponding bindings. The minimum frequency and run allowance depend on your plan. The example uses a one-hour interval; check the workspace’s limits before selecting a faster schedule or additional regions.
Do not send an inline config.script or HTTP-monitor assertion objects for a code monitor. The package contains the test and its assertions. An environment is required.

​
Inspect the result

Open the monitor in the dashboard and inspect its run history. A failed request or assertion makes the test fail. Review the recorded evidence and runner output to understand which condition was not met. Run now is a real run, with normal usage accounting. The synchronous uptime-monitor Test action is not supported for this check type.

​
Update the test

Package the changed files and compute the new ZIP digest. Request a signed upload URL and upload those bytes before updating the monitor’s package metadata. Keep the entrypoint, file list, and optional Git attribution aligned with the uploaded revision.

Synthetics overview

Choose Browser or API checks and understand their schedules and evidence.

API authentication

Set up access to the workspace that owns your monitors.