SDK

The Deepline SDK connects TypeScript code to Deepline. It supports two related jobs: defining work that runs inside a Play, and calling Deepline from an application or script. The SDK uses the same workspace and remote execution model as the CLI and web app. A custom Play can combine tools, datasets and other Plays. An application can start that Play, retain its run ID and retrieve the result later. These two sides use different objects because one describes the workflow and the other controls its execution.

​

Inside a Play: describe the work

A Play file imports deepline and default-exports an async function of its input. The function’s parameter and returned object define its input and result. Optional export const config supplies its name, description, triggers, and limits. Runtime methods create observable units of work: TypeScript describes the expected input and result. Deepline’s authoring checks validate supported structure, tool contracts and configuration before execution. The admitted graph connects these operations to the Play’s run history. The execution model supports ordinary business logic while requiring supported boundaries for durable work. Explicit freshness settings control reuse for new operations. Recovery of completed work within an interrupted execution is a separate concern. Inline deepline.runPlay composition uses compatible scalar children within one parent run. A child with datasets, CSV, event waits or an explicit timeout cannot use that path. Supported sequential sleeps remain possible outside dataset callbacks. deepline.runPlayAsync launches a separately published scalar child and returns its run ID without waiting for its result. That target can suspend for events or human responses, but cannot own a dataset, CSV or runtime sheet. Its admitted run continues independently after parent completion or cancellation.

​

Outside a Play: own the request and its observation

An application connects with workspace authorization and starts a saved custom or prebuilt Play by name. Starting returns a job handle with a public run ID. The application can wait for the result or return immediately and observe the same run later. The handle supports result retrieval, progress observation and explicit stop operations. A lower-level DeeplineClient supports reads by saved run ID. The client also exposes supported tool, Database, Monitor, workspace and usage operations. Exact methods and types belong in the SDK client reference. The remote run can outlive an HTTP request, worker or script. Saving launch intent and the returned run ID lets another worker reconcile the same request. A local timeout ends the caller’s wait, not the remote execution. Applications also choose who validates and writes accepted results. They can poll for completion, receive an authenticated callback from a custom Play, or let the Play own a destination write. The application integration guide explains those choices.

​

Named and prebuilt Plays share an invocation model

A custom published Play contains your versioned workflow. A prebuilt Play provides maintained logic with a defined contract. Both receive the input their contract supports and produce a Play run. File-based development submits a snapshot of local TypeScript source for remote execution. deepline plays run -e also accepts a short function body for an inline run from the current project folder. Named invocation resolves the selected saved revision. Publishing a new version changes what future callers can select while existing runs retain their admitted snapshot. Tools are smaller building blocks. A direct tool request performs one supported operation without requiring a custom Play. A Play becomes useful when you need selection rules, several operations, row processing or a reusable result. Direct tool requests have their own recovery contract.

​

Triggers extend the caller boundary

A published Play can declare webhooks, cron schedules and supported SQL listeners. Deepline then starts runs from events or time rather than an application’s direct invocation. Play triggers explains their inputs and lifecycle. A Monitor supplies a provider event feed. Its retained rows can start a listener-driven Play. SDK client authorization and Monitor feed activation remain separate operations.

​

Other ways to call Deepline

The CLI uses the SDK and exposes agent-callable commands for discovery, execution and observation. The web app uses the same workspace-owned Plays and runs. Work started through one interface can be inspected through another. Python and other HTTP-capable systems can call the Runtime API. They invoke saved Plays and retain run IDs, while custom Play source remains TypeScript. Credentials belong in the trusted caller environment rather than browser code or Play inputs.

​

Choose the practical guide

Use the SDK reference for runtime methods and Runtime API reference for HTTP contracts.