unit U1 — 1 of 4

Triggers & polling

webhook, schedule & app triggers

Every flow begins with exactly one trigger — the event that starts it. Three families cover almost all client work: a Webhook trigger fires the instant an outside system POSTs to the flow’s catch-URL; a Schedule trigger runs on a clock when the source can’t push; an app trigger (Gmail, Slack, HubSpot) wraps a provider’s own change feed. The trigger you pick sets the latency, cost, and reliability of everything downstream — choosing a poll where a push exists means lag or wasted API calls the client will feel.

The decision is about who initiates. If the client’s system can POST to a URL, use a Webhook trigger and react in real time — the engine mints a unique catch-URL and you send it a sample request to capture the shape of the data. If the source only exposes a “list records” endpoint, a Schedule trigger polls it at an interval you tune to the data’s freshness and the API’s rate limit, keeping a cursor (a timestamp or last-seen id) in the flow’s store so each run fetches only what’s new. App triggers are best when they exist — the engine manages the subscription and hands you deduplicated events.

Where it breaks: polling too aggressively. A one-minute Schedule against an API that changes a few times a day burns huge request volume for nothing and gets the key rate-limited. Match the interval to how fast the data really moves.

worked example

A Schedule trigger + HTTP Request Piece pulling only records changed since the last run.

[Schedule trigger · every 15 min]
        |
        v
[HTTP Request Piece]  GET https://api.acme-crm.dev/v2/contacts
   query:  updated_since = {{ store.cursor }}
   header: Authorization = Bearer {{ connections.acme.token }}
        |
        v
[Code Piece]  store.cursor = new Date().toISOString()   // advance for next run

field checklist

Use a Webhook trigger whenever the source can push events.
Reserve Schedule triggers for poll-only APIs.
Prefer native app triggers — they deduplicate events for you.
Keep a cursor between polls; fetch only new records.
Match the poll interval to data freshness, not the smallest number.

common failure — Polling faster than the data changes

A 1-minute Schedule polled a system that changed a few times a day, making ~1,400 empty calls daily until the provider rate-limited the key and the flow silently stopped returning data. Widen the interval to real change frequency, page from a stored cursor, and switch to a Webhook or app trigger when the source supports push.

check your understanding

A client CRM changes a handful of times a day and exposes both a "list records" endpoint and outbound webhooks. Which trigger should the flow use, and why?

next unit opens once this is passed

sandbox validation

The check above confirms you followed the unit. Marking the module COMPLETED takes more: build the automation in your own engine and submit the exported flow and its run evidence, signed, to your unique validation URL. See the module page for that spec.