> ## Documentation Index
> Fetch the complete documentation index at: https://deepline.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Deepline SDK

> Define, run, and operate durable GTM Plays from TypeScript, the CLI, or HTTP.

> [!NOTE]
>
> Beta: the SDK is usable, but its public surface is still evolving.

The SDK serves two related roles. It describes work that runs **inside
Deepline**, and it lets code **outside Deepline** start and observe that work.
Those roles share a Play model, but have different lifetimes and responsibilities.

## Inside a Play: describe the work

A Play handler uses runtime context methods to call tools, record steps, create
datasets, compose compatible scalar children, and make recorded external
requests. The runtime can inspect and retain those operations because they
have explicit identities and supported contracts.

A dataset is row-oriented work within the run. A scalar child Play is a reusable
computation within its parent's lifecycle. They are not interchangeable:
a child with its own dataset or waiting boundary cannot automatically be
embedded as an inline call.

The authoring surface is more constrained than arbitrary application code.
Deepline needs to admit a supported execution graph and bindings before it can
run the artifact. TypeScript helps describe inputs and outputs, while authoring
checks validate the supported shape. Neither proves the business answer.

## Outside a Play: own the request and its observation

An application starts an admitted Play and receives a job identity. That
application decides where to persist the identity, how long to wait, and what
to do with the result. A CLI or agent is another caller of the same remote work.

An application's HTTP lifetime is usually shorter than the job's lifetime.
If a worker stops polling, the run can continue. Recovering observation of the
same run is therefore a separate operation from submitting new work.

The SDK provides convenient handles for this distinction. Raw HTTP callers
still have to interpret the response package and preserve the public run ID.
Choosing a synchronous wait changes the caller experience, not the need to
understand remote execution and failure.

## Named and prebuilt Plays share an invocation model

An owned Play preserves your business rule. A prebuilt Play supplies maintained
logic with a published contract. Both can be invoked with an appropriate input;
a prebuilt title alone does not establish that it accepts your file or desired
identifier.

A tool is lower-level: one provider-backed operation. A Play can combine tool
results with validation, selection rules, and destination actions. The extra
layer is useful when the outcome needs more than one request.

## Triggers extend the caller boundary

Schedules, inbound webhooks, and supported SQL listeners provide automated
entry points. They supply timing and input to admitted logic. They do not move
all workflow policy into a scheduler or make an external source a trusted fact.

A Monitor remains a separate event-ingestion component. Its accepted rows can
start a listener-driven Play, but setting up an SDK client alone does not
subscribe the workspace to an external feed.

## Choose the practical guide

| Your task | Guide |
| - | - |
| Run one maintained workflow | [SDK quickstart](https://deepline.com/docs/sdk-v2/quickstart.md) |
| Define custom business logic | [Write Plays](https://deepline.com/docs/sdk-v2/plays.md) |
| Choose or compose a maintained contract | [Prebuilt Plays](https://deepline.com/docs/sdk-v2/prebuilt-plays.md) |
| Process a file and inspect its rows | [Batch CSV enrichment](https://deepline.com/docs/sdk-v2/batch-csv.md) |
| Start work from an application | [Call Plays](https://deepline.com/docs/sdk-v2/calling-plays.md) |
| Recover observation and write outcomes | [Production integration](https://deepline.com/docs/sdk-v2/production-integration.md) |
| Configure automated entry points | [Webhooks and schedules](https://deepline.com/docs/sdk-v2/webhooks-and-schedules.md) |

For exact methods, fields, and supported types, use the
[SDK reference](https://deepline.com/docs/sdk-v2/sdk-reference.md) and
[Runtime API reference](https://deepline.com/docs/sdk-v2/api-reference.md).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.