Skip to main content
Use this guide to deploy a scoped provider event feed. A Monitor receives events pushed into Deepline by a supported external source and writes accepted rows to Customer DB. A Play is separate: it runs code when a matching row reaches a stream.
A Monitor accepts data; it does not contain the code that reacts to it. Read How Monitors work for the product model.

​
Before you start

You need an authenticated Deepline workspace with Monitor access. Know which source events you want to accept and the smallest scope that produces useful data.

​
1. Check access and inspect supported types

The list returns the Monitor tool IDs available to your workspace. Replace deepline_native.company_radar with one of those IDs, then use its returned payload schema. Available Monitor types, streams, output tables, and pricing depend on your workspace and the provider. If the source might already be covered, inspect the existing registry before you deploy another feed:
One Monitor can supply a stream to several Plays. Reuse a Monitor when its existing scope already covers the events you need.

​
2. Define the narrowest useful scope

Save a definition as monitor.json. This example watches job openings at one company through the Deepline Native company radar:
Replace the key and payload with the schema returned by deepline tools describe deepline_native.company_radar --json. Scope the Monitor itself rather than accepting a broad feed and filtering only in a Play. For an event-priced Monitor, a Play filter does not reduce the events the Monitor accepts.

​
3. Validate without deploying or spending credits

check validates the definition. It does not deploy a Monitor, create an upstream resource, or spend credits. Resolve every validation error before you continue.

​
4. Preview the deployment, then deploy

The dry run shows the deployment plan, including available price information and any existing Monitor that may already cover the scope. It does not deploy or change upstream resources. If the scope and price are right, deploy the definition:
This is the step that activates the provider event feed. Monitor pricing can apply at deployment or reactivation, per accepted event, or at renewal. The CLI shows Deepline credits, not provider spend.

​
5. Confirm the live Monitor

Confirm the Monitor is active, its output stream and Customer DB table match the intended data, and its scope has not widened. The response also shows connected Plays and their current listener health when available.

​
6. Connect a Play to the stream

Generate a Play scaffold for the Monitor’s exact tool and stream:
The generated Play uses a sqlListeners trigger. Keep the tool and stream aligned with the Monitor, then narrow its where filter to the rows that should run code. Put joins and business decisions in the Play body, not in the Monitor definition. Check and publish the Play when its logic is ready:
After publishing, a matching Customer DB row starts the Play. There is no polling job or manual Monitor run.

​
Change or remove a Monitor safely

Inspect the Monitor and its connected Plays before changing it. Its output stream can also feed queries, dashboards, exports, or warehouse jobs.
Delete only after reviewing the plan. The actual deletion command deprovisions the upstream provider resource:

How Monitors work

Understand the event path and the boundary between a Monitor and a Play.

Where data lives

Decide when an event belongs in Customer DB and when an outcome belongs in a CRM.

Monitor contract reference

Inspect supported Monitor payloads, streams, outputs, and update semantics.