Choose the source of work
Manual calls can use the web app, CLI, SDK or Runtime API. They do not require
an automated binding. A local file run submits the handler’s code snapshot
without activating its declared schedule or webhook.
Automated bindings live in the Play file’s exported
config object and belong
to the published Play. One Play can declare several trigger types, provided its
function understands each input shape. Checking a file validates the declaration.
Publishing activates the selected definition.
Webhooks bring input from another system
Deepline issues a webhook URL for a published webhook binding. The sender posts the Play’s input there. A lead form, CRM relay or application event can use this path to start a workflow without waiting for a schedule. The Play can declare a signature verification contract. Deepline verifies configured signatures before the handler runs. The sender or relay must use the matching format and signing secret. An empty webhook declaration alone does not authenticate the sender. A stable delivery identity lets Deepline recognize a retry of the same event. Supported headers include explicit deduplication keys and delivery IDs from supported webhook formats. Repeating identical JSON alone does not establish that identity. A new business event needs a new delivery ID. An accepted webhook acknowledges intake, which can precede execution. The resulting run and its retained state show whether the Play started and finished. A sender retry and a deliberate new invocation are different operations. The webhook guide explains authentication, delivery header precedence and how to inspect the issued binding.Cron schedules start work at known times
A cron binding declares a schedule and timezone. It can also declare static JSON input. Without that input, the handler receives{}. Input from a
previous manual run does not become the schedule’s input.
For example, a daily refresh can select accounts that need current evidence,
then process them as a dataset. The schedule supplies the occasion. Account
selection, overlap policy and acceptance rules remain in the Play.
The published binding controls future occurrences. A scheduled run uses its
admitted version, so later source edits do not alter a run already underway.
Timezone, input and publication state all affect what the automation does.
Billing restrictions can suspend scheduled work. Recovery depends on the
recorded reason. A balance correction can recover eligible insufficient-credit
suspensions, while a customer-paused schedule remains paused until explicitly
resumed.
SQL listeners react to retained row changes
A SQL listener connects a published Play to a supported tool and stream. Deepline resolves that stream to its Database table. The binding selects operations such as inserts or updates and can apply row-level filters. Each listener invocation receives one event containing the operation, stream, before/after rows and change metadata. Inserts have no before row. Deletes have no after row. Updates carry both. A listener can filter for relevant changed values, then let the Play query other records and apply business rules. Joins and broader decisions belong in the handler rather than its row-level filter. A Monitor often supplies the source events. The listener subscribes to the tool’s stream, not a private queue for one Monitor key. Several Plays can consume accepted data from the same stream. A listener also differs from a periodic query over all accumulated rows.Publication and lifecycle controls
Publication activates declared bindings for the selected Play revision. Removing a binding changes future entry points. Existing runs retain their own execution identity and need separate cancellation when appropriate. Removing a webhook retires its URL. Re-enabling it issues a new URL, so the sender configuration also needs to change. A schedule or listener likewise needs its own control rather than relying on the stop state of one run. The lifecycle boundaries are separate:- Disable a trigger to prevent its future work.
- Stop a run to cancel an execution already started.
- Change a Monitor to alter its upstream feed and accepted source data.
Observe automated work
The active binding explains what should start a run. Play runs show what happened after launch. Source delivery and downstream execution can fail independently, so both need observation. Notification settings can route supported scheduled and webhook Play outcomes. Configured rules, destinations and recipient preferences determine delivery. The notification settings and trigger setup guide explain the available checks.Continue learning
- Schedule or trigger a Play: configure webhooks and cron schedules.
- Set up a Monitor: supply a feed and connect a SQL listener.
- Play runs: inspect execution, results and cancellation.
- SDK reference: exact binding and event contracts.