Firehook in practice

How Firehook works

Firehook lets you trigger webhooks and API calls as fast actions. It’s designed to be simple to use, yet flexible enough for power users who already automate with tools like IFTTT, n8n, Pipedream or Home Assistant.

What Firehook does

A “hook” is a button you configure to call a URL (webhook), optionally with headers, a body, and variables. One tap can start a workflow, toggle a device, call a personal API, or notify a service.

Firehook is intentionally generic: it doesn’t replace your automation tools, it helps you trigger them quickly—especially from contexts where typing is painful (car screen, quick actions, widgets).

The typical flow

1) Create

Define a hook: endpoint, method, headers, body, variables, and optional options.

2) Test

Run it from your phone to validate the request/response and adjust your payload.

3) Trigger

Use it anytime: phone, shortcuts, and car screen (CarPlay / Android Auto).

Firehook aims to keep the “tap → action” loop fast and predictable, even when your underlying workflow is complex.

Where hooks are executed

Hooks are triggered from your devices. Firehook is built so that requests are initiated by the user’s phone/car session—not executed as a batch job on Firehook servers.

Why it matters

This approach reduces central processing and keeps execution closer to the user context (permissions, network, and intent).

Depending on the destination, the call may still reach third-party services (IFTTT, n8n, Home Assistant, eWeLink, cloud APIs, etc.). You remain in control of what you connect.

Where hooks and variables are stored

Hooks and their configuration are stored in your environment. Variables can be used to avoid hardcoding secrets directly in hook bodies.

Some variables may contain sensitive values (tokens, IDs, URLs). Firehook is designed to minimize accidental exposure in the UI and during normal usage.

Hooks

Definition of the request: method, URL, headers/body template, and options.

Variables

Reusable values injected at runtime (ex: {token}, {homeId}, {device}).

When encryption is enabled for variables, Firehook encrypts data before storage using strong, standard cryptography (AES-based). The goal is to protect secrets at rest in your environment (for example, if a device backup is compromised).

Works with your existing automation stack

Firehook is friendly with common stacks: n8n, IFTTT, Pipedream, Home Assistant, eWeLink, Alexa routines, and custom endpoints.

n8nIFTTTPipedreamHome AssistanteWeLinkAlexa

In practice, Firehook often becomes the “remote control” for workflows that already exist elsewhere.

Power features (now and next)

Firehook is evolving. Some capabilities are already present, others are planned. The goal is to stay minimal while covering the real-life use cases that made you build automations in the first place.

Stateful hooks — Keep track of a state (on/off, opened/closed) using responses or status checks to display meaningful feedback.
Geofence — Trigger hooks when you arrive/leave an area (ex: open gate, turn on lights, send an “I’m home” ping).
Deep links — Open a specific screen/action from a link—useful for sharing and for quick launch from other apps.
Bluetooth — Interact with nearby devices when local control is possible (future direction).
MQTT — For self-hosted or local-first setups, MQTT is a natural path for low-latency control (future direction).
Hook sharing — Share a hook template with family/friends without exposing secrets (future direction).

Planned features may change depending on platform constraints (especially car platforms) and security considerations.

FAQ

Not really. Firehook is a fast trigger layer: a convenient way to launch what you already built elsewhere.

No. Hooks are triggered from your devices. You decide the destination services and what data you send.

Yes—typically through webhooks, local endpoints, or APIs you already expose. Firehook stays tool-agnostic.

See tutorials Explore examples