IFTTT Filter Code: Conditional Logic Without the Middleware

The Problem: Linear Applets Multiply

You have a webhook from monitoring that posts to Slack. Now you want the same webhook to email the on-call engineer, but only for high-severity alerts. The default IFTTT pattern is to create another applet. Two applets become four, then eight. Every change to the trigger URL or payload shape has to be mirrored across all copies. Filter Code lets you collapse that sprawl into one multi-step applet that branches.

What Filter Code Actually Is

Filter Code is a sandboxed JavaScript snippet that sits between a trigger and actions in a multi-step applet. It receives the trigger payload via the trigger object and controls execution with IFTTT.setAction('ActionName') or IFTTT.skip().

The sandbox is an ES6 subset with a 100ms execution ceiling and a 1MB memory cap. It provides IFTTT.log() for debugging visible in the activity feed, and Meta.currentUserTime for timezone-aware timestamps. No outbound HTTP requests, no Node.js built-ins like fs or net, and no eval or Function constructor. All logic must be self-contained.

Worked Example: Severity-Based Routing

A monitoring system POSTs JSON to an IFTTT Webhook trigger:

{
  "service": "payments-api",
  "severity": "high",
  "message": "Latency p99 > 2s",
  "timestamp": "2026-10-03T22:15:00Z"
}

Goal: high or critical severity goes to #oncall Slack, everything else goes to #alerts Slack. One applet, two Slack actions named "Slack Oncall" and "Slack General". Filter Code:

const sev = (trigger.body.severity || '').toLowerCase();
if (sev === 'high' || sev === 'critical') {
  IFTTT.log('Routing to oncall: ' + trigger.body.message);
  IFTTT.setAction('Slack Oncall');
} else {
  IFTTT.log('Routing to general: ' + trigger.body.message);
  IFTTT.setAction('Slack General');
}

Test from a terminal with network access to the webhook URL. No special permissions are required beyond the URL:

curl -X POST -H "Content-Type: application/json" -d '{"severity":"high","message":"test"}' [YOUR_WEBHOOK_URL]

Expected checks: open the applet activity feed and confirm IFTTT.log() output appears and only the selected Slack action runs. Risk: if the filter exceeds 100ms, the run terminates silently and all actions are skipped.

Time-Based Filtering Without External Scheduling

Meta.currentUserTime provides hour, day, etc. in the user's timezone. This enables business-hours gating without a separate scheduler.

const hour = Meta.currentUserTime.hour;
if (hour < 9 || hour > 18) {
  IFTTT.log('Outside business hours, skipping.');
  IFTTT.skip();
}

Use this to suppress non-urgent notifications off-hours while still allowing high-severity routing above.

Trade-offs and Limitations

Execution timeout is strict. Complex loops or heavy string manipulation can terminate the filter silently, skipping all actions. Test with realistic payload sizes and log start/end timestamps with Date.now() to verify runtime stays well under 100ms.

The editor lacks linting, type checking, or local development. Syntax errors surface only at save time, and debugging relies on IFTTT.log() in the activity feed.

Changes apply immediately to future runs. There is no versioning, staging, or rollback. Export applet JSON via the IFTTT platform UI before major edits to preserve the serialized Filter Code and action mapping.

Sandbox restrictions block third-party libraries. Complex integrations that need outbound HTTP must push logic to an external endpoint via a Webhooks action. Rate limits on underlying services still apply per-action; Filter Code cannot batch or throttle.

Actionable Closing

Build a safe test first: Webhook trigger → Filter Code → two actions. Use IFTTT.log() to verify each branch, confirm only the intended action executes per payload, and measure execution time. Once stable, replace duplicate applets with one branching applet and export the JSON for documentation.