IFTTT
ProductivityFire a named IFTTT event from any flow through the Webhooks service, triggering every applet listening for it. Agents reach consumer devices and services that expose no direct business API.
What This Integration Enables
IFTTT connects a long tail of consumer services and household devices that publish no business API of their own, and this connector reaches them through the Webhooks service in the simplest possible way: a flow fires a named event, and every applet built on the "Receive a web request" trigger with that name runs. Lights, plugs, speakers, wearables, notes apps, personal spreadsheets and phone notifications all become reachable from a FlowRunner flow without building a connection to each one. Two payload styles are supported: the classic form passes up to three string values through as the Value1, Value2 and Value3 ingredients, and the JSON form delivers an arbitrary object as a single JsonPayload ingredient for parsing with IFTTT filter code.
The strategic shape matters as much as the technical one. This is a one-way outbound bridge and it is deliberately shallow, because the orchestration belongs in FlowRunner. The flow holds the state, the retry behavior, the audit trail and the moment where the run stops and asks a person. IFTTT is the last hop, and it is a good last hop precisely because the applet on the other side can be edited by a colleague who will never open a flow editor. Traffic in the other direction does not need this connector at all: an IFTTT applet can call a FlowRunner webhook directly with its own "Make a web request" action, which is why the connector ships no triggers.
Without FlowRunner
With FlowRunner
Use Case Scenarios
On-call alerting that reaches past the screen
A monitoring agent watches the overnight fulfilment batch. When a run stalls past its cutoff, the agent classifies the failure, checks it against the last successful run, and fires a single event carrying the failed step and the affected order count as Value1 and Value2. On the engineer's side, three applets are subscribed to that event name: one pushes a phone notification, one buzzes a wearable, and one turns a lamp red. The engineer acknowledges from their phone, and the agent resumes with the instruction rather than continuing to guess. The escalation crossed from a dashboard into the room.
Facility signals driven by business logic
A logistics flow tracks inbound receipts against dock availability. When the yard reaches capacity, the agent fires an event that switches a status display in the warehouse office and posts a note to the shift supervisor's phone. When the last receipt of the shift is closed, a second event resets the display. None of those endpoints expose an API a business system could call directly, and none of them needed one. The rule that decides when to fire lives in the flow, where it can be versioned, audited and changed by whoever owns the process.
Fanning one event out without building each integration
A milestone in a customer onboarding flow needs to reach four places that are individually too small to justify a connector: a personal task list, a habit tracker, a team's shared spreadsheet and a smart speaker announcement. The agent calls Fire Event With JSON Payload once with the full onboarding record, and four applets parse the payload with filter code and take their own action. When someone wants a fifth destination, they add an applet. The flow does not change, and neither does its test coverage.
Human-in-Loop Highlight
Firing an IFTTT event has a blast radius the flow cannot measure. Every applet subscribed to that event name runs, IFTTT publishes no way to enumerate which applets those are, and the applets themselves are owned and edited by people outside the automation. That is a genuine strength of the model and it is also why the first fire of a new event name deserves a person. The same operation that turns on a lamp can unlock a door, cut power to a plug or announce a customer's name out loud in a shared office, and the flow gets an identical success response in every case. The Verify Webhook Key check has the same edge: because IFTTT publishes no dedicated key-validation endpoint, the check sends a real request to the trigger endpoint with a probe event name, and if any applet happens to listen for that probe name, it runs.
So FlowRunner gates the name, not the message. The first time a flow fires an event name, and again whenever the name is assembled at runtime rather than fixed in the step, the agent stops and asks the process owner in Slack: "About to fire the IFTTT event yard_at_capacity for the first time from the receiving flow. I cannot list what is subscribed to it. Confirm what this event drives, or give me a different name." Once the owner confirms, the flow fires that name unattended forever. It is a single question, asked at the only moment where a person can still see what is on the other end of the wire.
Agent Capabilities
3 actionsEvents
2- Fire Event Fires an IFTTT Webhooks event, running every applet that uses the "Receive a web request" trigger with the matching event name. Used for alerts, milestones and physical signals where the payload fits into a few flat values. Up to three optional string values are passed through as the Value1, Value2 and Value3 ingredients, sent as a JSON body by default and optionally as query parameters or form variables instead. Event names may contain only letters, numbers and underscores.
- Fire Event With JSON Payload Fires an IFTTT Webhooks event with an arbitrary JSON payload, running every applet that uses the "Receive a web request with a JSON payload" trigger with the matching name. Used when the data will not fit into three flat strings, for example handing a whole record to several applets that each parse the parts they care about. The full body arrives as the single JsonPayload ingredient and is parsed with IFTTT filter code.
Account
1- Verify Webhook Key Checks whether the configured Webhooks key is accepted by IFTTT. Used during setup and when diagnosing silent delivery failures. IFTTT publishes no dedicated key-validation endpoint, so this sends a real request to the standard trigger endpoint with a probe event name and reports whether the key was rejected, returning the IFTTT error message when it was. Choose a probe name that no applet listens for, because an applet subscribed to it will run.
Frequently Asked Questions
What can FlowRunner do with IFTTT?
FlowRunner agents can run Fire Event, Fire Event With JSON Payload, and Verify Webhook Key in IFTTT.
Does connecting IFTTT to FlowRunner require OAuth?
No. IFTTT connects to FlowRunner with an API key, no OAuth flow required.
Can IFTTT trigger a FlowRunner workflow automatically?
IFTTT doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with IFTTT
$100 in credits. No card required. Connect in minutes.