Skip to main content
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 handler 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. This minimal Play has no required input, so its scheduler can invoke it directly:
Move your account selection and enrichment logic into the handler. 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 checked handler before the next schedule or external event. It does not substitute for testing sender authentication or observing the published binding.