Skip to main content

​
Overview

Standalone Runs let you execute browser automations on demand. It’s the simplest way to run your browser automations. Use Standalone Runs when you need to trigger a browser automation:
  • In response to user actions — Submit a form when a user clicks “Apply Now”, fetch account details on request, or pull data when a customer connects their account
  • As part of a workflow — Scrape data for a single item, validate a URL, or extract information from a page as one step in a larger process
For batch processing or scheduled executions, see Jobs (batch executions).
The Run Playground in the dashboard lets you trigger Runs manually—useful for testing your automations before integrating them into your application.

​
How it works

​
Project configuration

Standalone Runs require API access to be enabled in your project settings. You also need to set a maximum concurrent requests limit to control how many Runs can execute at the same time.
Select Files > Intuned.json. Update the settings as needed.API access and maximum concurrent requests in the online IDE
When you deploy your project, Intuned creates machines equal to your maximum concurrent requests setting. Each Run is picked up by one machine. If all machines are busy, the Run waits in a queue. Machines are only active when processing Runs—you’re not charged for idle time.
Your workspace has a limit on total deployed machines across all projects. Contact support if you need to increase this limit.

​
Triggering a Standalone Run

Before triggering a Standalone Run, make sure your project is deployed.
Call the Run start endpoint with the API name and parameters. The response includes a Run ID that you can use to monitor progress and get results. Then use the Run result endpoint with the Run ID to check status and get the result when complete.
const result = await intuned.project.run.start(
  projectName,
  {
    api: "<api-name>", // Name of the API to execute
    parameters: { // Parameters to pass to the API

    },
    retry: { // (Optional) retry configuration
      maximumAttempts: 3, // (Optional) Maximum number of Attempts for the Run. Default is 3
    },
    requestTimeout: 600, // (Optional) Timeout for an Attempt. Default is 600 seconds (10 minutes)
    proxy: "<proxy-url>", // (Optional) Proxy URL to use for the browser during the Run
    saveTrace: true, // (Optional) Whether to save a browser trace for the Run. Default is true
    authSession: { // AuthSession configuration. Required for authenticated Projects

    },
    sink: { // (Optional) Sink configuration to send Run results to external systems

    },
  }
);

console.log(`Started run ${result.runId}`); // Run ID

// Poll for results (or use sinks to receive results automatically—see "Get results without polling" below)
while (true) {
  const runResult = await intuned.project.run.result(
    projectName,
    result.runId,
  );

  if (runResult.status === "pending") {
    await new Promise(resolve => setTimeout(resolve, 5000)); // Wait before checking again
    continue;
  }

  console.log(`Run ${runResult.runId} finished with status ${runResult.status}`);
  // Process results
  break;
}

​
Get results without polling

Intuned supports webhook and S3 sinks to deliver Run results automatically when complete. 
await client.project.run.start(
  projectName,
  {
    sink: {
      type: "webhook",
      url: "<webhook-url>",
      headers: { // (Optional) Additional headers to include in the webhook request. Useful for authentication
       //...
      },
      skipOnFail: false, // (Optional) Whether to skip sending the webhook if the Run failed. Default is false
    },
    // ...
  }
)

​
AuthSession Support

For authenticated Projects, each Run must specify an AuthSession to use. Before each Attempt runs, Intuned automatically validates the AuthSession and can recreate it if needed. This ensures your automation code never runs with an invalid session.
Before triggering a Run, you need an AuthSession created. Check out AuthSessions - Create an AuthSession.
Specify the AuthSession to use in the run configuration:
await intuned.project.run.start(
  projectName,
  {
    authSession: {
      id: "<auth-session-id>", // Auth session ID to use for the Run
      autoRecreate: true, // (Optional) Whether to automatically recreate the auth session if initial check fails. Default is true
      checkAttempts: 3, // (Optional) Number of attempts to check for session validity. Default is 3
      createAttempts: 3, // (Optional) Number of attempts to create a new session if needed. Default is 3
    },
    // ...
  }
)
Intuned supports different types of AuthSessions. Check out AuthSessions - AuthSession types for more information.
Each Attempt will produce an AuthSession Validate Run before it executes to ensure the session is valid.

​
Execution model

When you start a Standalone Run, it executes a single API with the parameters you specify. Browser automations can sometimes fail due to temporary issues (network problems, element not found, timeouts). To handle this, Runs support automatic retries through multiple Attempts. The Run will try one or more Attempts until it succeeds or runs out of retries. Each Run produces a result or error based on the final Attempt’s outcome. Each Attempt has its own result or error, along with detailed logs and a browser trace for debugging. The Run starts in a Pending state, transitions to Started when an Attempt begins, and finally to Success, Failed, or Canceled based on the outcome. For more details about Runs and Attempts, see Intuned in depth: Runs and Attempts.

​
Monitoring

Intuned tracks every Run and its Attempts, giving you full visibility into your automation executions. From the dashboard, you can view Run records, inspect individual Attempts, and access detailed logs and browser traces for debugging. For more details, see Monitoring and traces.

​
Best practices

  • Choose an appropriate maximum concurrent requests value based on your expected load. While you’re not charged for idle compute time, setting a reasonable limit helps manage resource usage effectively.
  • Set request timeouts to reasonable values to ensure that failed Attempts are detected quickly, allowing for faster retries and reducing overall execution time.
  • Use sinks (webhook or S3) to receive Run results automatically, reducing the need for polling and improving efficiency.
  • If your use case involves batch or scheduled executions, consider transitioning to Jobs for better management and scalability.
  • Set appropriate retry attempts. Increase retries for websites with flaky behavior or network issues to improve success rates.

​
Limitations

  • Workspace machine limit: Your workspace has a limit on total deployed machines across all projects. If you need more capacity, contact support to increase this limit.
  • Sink delivery is at-least-once: Results sent to sinks may be delivered multiple times in rare failure scenarios. Make sure your webhook or processing logic handles duplicate deliveries idempotently.

​
FAQs

Standalone Runs execute a single API immediately when you call the endpoint. Jobs orchestrate multiple API executions together with scheduling, retries, and concurrency management. Use Standalone Runs for one-off or user-triggered executions; use Jobs for batch processing and recurring automations.
Each Run can have multiple Attempts. If an Attempt fails, Intuned automatically retries up to your configured maximumAttempts (default is 3). Each Attempt has its own logs and browser trace for debugging. The Run succeeds if any Attempt succeeds, and fails only after all Attempts are exhausted.
Yes. Use the Run cancel endpoint with the Run ID to cancel a pending or running Run. The Run status changes to Canceled.
Each Attempt has a configurable requestTimeout (default 600 seconds / 10 minutes). If an Attempt exceeds this timeout, it fails and triggers a retry if attempts remain. For long-running automations, increase the timeout or use extendTimeout within Jobs.

AuthSessions

Authenticated browser automations

Run API reference

Programmatic access to Standalone Runs

Sinks API reference

Webhook and S3 result delivery

Monitoring and traces

Debug and monitor Run executions