Learn n8n - Triggers & Event Sources

#Introduction

In episode 4 you built your first webhook-triggered workflow and successfully sent an email. Now we'll break down trigger sources thoroughly — because the trigger is the first architectural decision that determines when and how a workflow runs.

This episode covers the trigger categories in n8n — webhook, cron, polling, and event-based — secure webhook configuration, and how to trigger workflows from cloud services and API integrations. By the end of this episode you can choose the right trigger for every scenario.

#Trigger Categories in n8n

Every workflow starts from a trigger node. Based on how it's triggered, there are four major categories:

One thing that often confuses beginners: for trigger apps like Gmail, n8n generally uses polling — checking the inbox at each interval, not receiving pushes. The consequence is a maximum latency equal to the polling interval. For near-zero latency, use a webhook.

#Webhook Trigger: Test vs Production Endpoint

The Webhook node turns n8n into an HTTP endpoint. When configured, n8n generates two URLs:

• Test URL at the /webhook-test/... path — only active while the workflow is in test mode, safe for experiments.
• Production URL at the /webhook/... path — only serves requests when the workflow is activated.

This difference is intentional: test mode prevents a half-finished workflow from being triggered by production events. Also remember that n8n returns HTTP 200 immediately once the payload is received — then the execution runs in the background. This makes n8n webhooks responsive, but it means you must ensure the payload is valid from the start because the workflow doesn't wait.

#Securing Webhooks: Auth, Headers, and Payload Validation

A webhook open to the internet is a tempting entry point for attackers. Tighten it with several layers:

1. Authentication — enable the auth option on the webhook node and set a specific header that must be present, e.g. x-api-key.
2. Validate the payload — after the trigger, insert an IF node to validate important fields; reject (or log) requests with suspicious formats.
3. Always HTTPS — behind a reverse proxy like Caddy or Nginx, with TLS. Plain HTTP endpoints are easy to intercept.

Example of testing a production webhook with an API key — run it via the terminal starting with curl -X POST http://localhost:5678/webhook/notifikasi-pesanan:

curl -X POST http://localhost:5678/webhook/notifikasi-pesanan \
  -H "Content-Type: application/json" \
  -H "x-api-key: rahasia-anda" \
  -d '{"nama":"Arief","email":"arief@example.com","total":1250000}'

With auth enabled, requests without the correct x-api-key header are rejected before the workflow runs — the flow stays secure even though the endpoint is public.

Also remember the principle of minimum exposure: don't activate unused webhooks, deactivate workflows when they're not needed, and restrict HTTP methods as needed. The fewer open endpoints, the smaller the attack surface.

#Schedule Trigger and Cron Expressions

For periodic work — morning reports, daily syncs, data cleanup — use the Schedule Trigger. Two main modes:

• Interval — run every X hours/minutes/days/weeks. The simplest to understand.
• Cron expression — precise Unix-cron style scheduling with five fields: minutes, hours, day of month, month, day of week.

Example cron: every day at 09.00 instance time — make sure you write this pattern directly in the cron field of the Schedule Trigger node, not in the terminal:

0 9 * * *

Important: schedules follow the instance timezone set via GENERIC_TIMEZONE (e.g. Asia/Jakarta). If the instance runs on a UTC server, 09.00 means a different hour than your local time — make sure the timezone is correct during setup.

#Polling and Triggers from Cloud Services

Many app triggers work by polling: at a certain interval, n8n calls the service's API to look for new data. Real examples:

• Gmail Trigger — checks for new emails and triggers a workflow when a new message arrives.
• RSS Trigger — fetches feeds and detects new items.
• Schedule Trigger + HTTP Request node — a manual pattern for polling APIs that don't have webhooks.

With polling, n8n remembers items that have already been processed so it doesn't re-trigger on old data. Since every poll is an execution, choose a balanced interval: too frequent wastes resources, too infrequent delays events.

A common practice: combine polling with other triggers. For example, schedule a poll with the Schedule Trigger then call the API via the HTTP Request node, or use a Gmail Trigger whose interval is set directly in the node configuration. The important thing is to always know the default and maximum interval of the node you're using, so your workflow latency expectations are realistic.

#Event-Based Triggers and API Integration

A number of nodes use pure event subscription: the service sends events to n8n without any polling needed. Examples include WebSocket triggers that listen to connections directly, or certain platform integrations that register a webhook back to n8n.

When to use which trigger? Use this rule of thumb:

• Real-time events + control over the service — webhook.
• Scheduled job without external input — schedule / cron.
• New data from a third-party API without a webhook — polling.
• Low-latency synchronization between platforms — event-based / WebSocket.

Your trigger choice determines the latency, load, and reliability of your workflows — take the time to choose correctly from the start.

#Closing

This episode mapped out all of n8n's trigger sources: webhooks for real-time events, cron for schedules, polling to pull new data from APIs, and event-based for direct synchronization — complete with webhook security practices and rules for choosing the right trigger.

Key takeaways:

• Triggers are divided into webhook, schedule/cron, polling, and event-based — each with different latency and load.
• Test and production webhooks have separate paths; production is only active when the workflow is running.
• Secure webhooks with auth headers, payload validation, and HTTPS.
• Cron follows the instance timezone — set GENERIC_TIMEZONE correctly.
• Choose polling when the API doesn't provide a webhook, and keep the interval within rate limits.

In the next episode, we enter the heart of data processing: nodes, data & transformation — how data flows between nodes, using the Set, Merge, and SplitInBatches nodes, data transformation, conditional logic, up to loop patterns. See you there!