Skip to main content
Job: make a workflow run when the business event happens.

Webhook: enrich inbound leads

The incoming JSON body becomes the play input.
This workflow receives an inbound lead payload.
HubSpot v3 signatures are not Standard Webhooks signatures. For HubSpot, put an authenticated relay in front of the Play. The relay verifies HubSpot’s signature, then signs the forwarded body with the Standard Webhooks v1 contract using webhook-id, webhook-timestamp, and webhook-signature. Store the relay signing secret in Deepline before publishing:
Start without HMAC only in an isolated test environment if your source allows it:
Add HMAC before production if the sender supports signatures.

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
The sender must reuse the same nonblank value only when retrying the same delivery. Different deliveries need different values. If none of these headers is present, every POST starts a new run. This is at-least-once delivery, so an unkeyed retry after a lost response can execute twice. Deepline does not infer delivery identity from identical JSON or a generic top-level id.

Schedule: refresh accounts

This workflow refreshes accounts on a schedule.
Use this when freshness matters more than a human clicking run.

Activation boundary

Trigger declarations are inert while the play is a draft. Check, then publish:
Then run a manual test before waiting for the schedule:
Manual tests prove the play logic before you wait for the next event.