Skip to main content
Write a Play when the business decision is yours: custom routing, a specific provider order, a scheduled refresh, or an outbound destination. Use a Prebuilt Play when the maintained contract already does the job.

Discover a live contract before provider work

Do not copy a provider ID or payload from an old example. Search the current workspace, then read the schema before you add a provider action:
deepline tools get free_simple_company_search --json remains a backward-compatible alias for tools describe; prefer describe in new automation. Save this first example as lead-routing.play.ts. Keep it decision-only and validate it before you add provider work:

The authoring contract

A deployable Play has one default definePlay(...) export, typed input, a plain-object return value, and a non-empty description. The handler runs in Deepline; ctx.* records the work that it performs.
This example composes a scalar prebuilt Play. It keeps one durable row per lead_id, so a failed row is visible rather than silently dropped.

Choose the runtime primitive

Use ctx.runPlay(...) for a Play, not ctx.tools.execute(...). A tool is one provider-backed operation. A child Play is reusable business logic and must be small enough to run inline; a child that owns a dataset, CSV, event wait, or explicit timeout must run as a top-level Play instead.

Validate before deployment or spend

This validates the Play without deploying it or starting provider-backed work. Fix the reported contract or authoring error before you publish or run it.

Add operational guardrails

Put durable operational policy next to the code it governs:
Use the smallest credit cap and schedule that fit the job. For a file pilot and export review, use Batch CSV enrichment. For trigger semantics, use Webhooks and schedules.

Next steps

Prebuilt Plays

Discover a maintained Play or compose a scalar child Play.

SDK reference

Read the exact definePlay, ctx, dataset, and tool contracts.