Skip to main content
Human guide: work with your agent →
Configure one authenticated or scheduled entry point and verify its input and delivery identity.
Use a webhook when another system decides when work starts. Use a schedule when time decides. Both bindings are part of the Play definition and become active only when you publish the checked Play.

Inbound webhook contract

The JSON request body becomes the Play input. Keep the input small and explicit:
This binding verifies a Standard Webhooks v1 signature before the play runs:
Set the secret through the hidden CLI prompt. do not put its value in a command, file, or agent prompt:
HubSpot v3 signatures are not Standard Webhooks signatures. Put an authenticated relay in front of a HubSpot-bound Play: verify the HubSpot signature there, then sign the forwarded body with webhook-id, webhook-timestamp, and webhook-signature under Standard Webhooks v1. Use webhook: {} only in an isolated test environment. Require signature verification before production whenever the sender supports it.

Webhook delivery identity

Deepline deduplicates a retry only when the sender supplies a stable delivery identity. Header precedence is:
  1. x-deepline-dedupe-key
  2. idempotency-key
  3. x-github-delivery
  4. x-shopify-webhook-id
  5. webhook-id
  6. svix-id
Reuse the same nonblank value only for a retry of the same delivery. Give each new delivery a different value. Without one, every POST begins a new run. Deepline does not infer identity from identical JSON or a generic top-level id.

Cron schedule

Use a five-field cron expression and an IANA timezone. A scheduled Play takes no required input. Save this as daily-account-review.play.ts:
Put your account selection and enrichment logic inside the function. If that logic processes rows, use a durable dataset as described in Write Plays.

Activate and test deliberately

Trigger declarations are inert while the play is a draft.
The manual run validates the play before the next schedule or external event. It does not substitute for testing sender authentication or observing the published binding.

Verify this task

Check and publish the source, then inspect the generated binding. Test repeated delivery separately from a new event. Ask your agent to explain a failed check before repeating work or expanding the scope.