Workflow Templates

Overview This workflow takes an image + instruction text from an n8n Form, edits only the hairstyle while keeping the face unchanged, uploads the result to Cloudinary, and pushes the image to a designated LINE group. It’s designed for salons or creative teams that need quick, consistent “hair-only” edits and one-click sharing to a staff group. Key Features Accepts image and free-form instructions via n8n Forms Enforces identity preservation: face is not altered; only the hairstyle is modified Uses OpenAI Image Edit to generate the edited image Uploads the output to Cloudinary and returns a public URL Sends the final image to a LINE group via the Push API (no replyToken required) Optional safety: store the groupId once (via webhook) in n8n Data Store and reuse it, avoiding mis-sending to individuals Requirements OpenAI API key (Image Edit capable model) Cloudinary account with an unsigned upload_preset LINE Official Account (Messaging API enabled) and the bot added to the target group (to capture groupId once) n8n with Forms enabled and Data Store available Notes Replace placeholders like CLOUDINARY_CLOUD_NAME, CLOUDINARY_UPLOAD_PRESET, LINE_CHANNEL_TOKEN, and LINE_GROUP_ID with your values.

System Prompt Generator Using Unli.dev turns human input ideas into a polished, repeatable system prompt blueprint. It uses an n8n webhook, a small Set/Prepare pipeline, and Unli.dev's chat completions to generate single-turn, comprehensive system prompts that include: persona mission rules output format designer notes so your team spends less time arguing about wording and more time shipping features (and you get consistent LLM behavior across apps). 💡 Why Use System Prompt Generator Using Unli.dev? Fix the pain of inconsistency** Improve outcomes measurably** Competitive advantage:** Standardize your AI behavior with enforceable rules and templates so your product's voice and constraints stay consistent across teams — like an AI style guide that never takes a coffee break. ⚡ Perfect For Prompt Engineers:** Systematize prompt design and handoffs. Product Managers:** Lock down expected AI behaviors before launch. Developers & AI Ops:** Automate prompt generation for testing and deployments. 🔧 How It Works ⏱ Trigger: Incoming HTTP POST to the webhook path systempromptgenerator kicks everything off. 📎 Process: Webhook → Set Prompt/Model (map incoming fields) → Prepare API Body (compose messages) → Unli.Dev (Chat Completions) → Extract Answer → Respond to Webhook. 🤖 Smart Logic: Unli.dev (chat completions) runs a single-turn generation using the embedded system-template that builds persona, operational protocol, rules, output format, and designer notes automatically. 💌 Output: The generated system prompt (with Designer's Notes) is returned in the webhook response for immediate use in your app or CI pipeline. ⚠️ Security Note: You'll want to swap in your Unli.dev API key under the HTTP header auth credential—don't share it in Slack. Seriously. 🧩 Requirements Active n8n instances Unli.dev API key / account HTTP Header Auth credential configured in n8n Optional: Postman or curl for testing 🛠️ Level Up Ideas Add a lightweight front-end form** to let non-technical PMs generate prompts and preview outputs Add validation rules** or automated tests that run generated system prompts against sample user queries to catch unwanted behavior early Made by: Khaisa Studio Category: system-prompt, unli.dev Need custom work? Contact me!

Workflow Overview This workflow benefits anyone, who: wants to automate sending Postcards to tagged CentralStationCRM contacts Tools in this Workflow CentralStationCRM - the simple and intuitive CRM Software for small teams. EchtPost - send postcards online Workflow Screenshot Workflow Description This workflow consists of: a webhook trigger a set node an if node an HTTP request The Webhook Trigger The webhook triggers when a person is updated in CentralStationCRM. The persons data is sent to n8n, including the company name and the address. The Set node This node filters the webhook data for just the data the EchtPost node needs. It also transforms the country field to the associated country code (i.e. "Deutschland" -> "DE") The if node This node checks if there is an "EchtPost" tag in the persons data. -> if false: do nothing -> if true: go to HTTP request The HTTP Request This node sends the persons name, address and country code alongside with the id of the EchtPost template (inserted manually in the node) to EchtPost. It also needs an E-Mail-Adress for a confirmation mail. The data starts a "Mail in 3 days" process with the EchtPost service, which mails a postcard with that template to the person. Preconditions For this workflow, you need: a CentralStationCRM account with API access an EchtPost account with API access an EchtPost template, with a message, and the templates ID

📊 YouTube Trends Workflow in n8n 🎯 Goal of the Workflow This workflow fetches the most popular YouTube videos in Germany and transforms them into a clean list of trending hashtags/keywords. It’s not just raw data – it highlights qualitative insights about which topics and keywords drive real engagement. Useful for: Content creators & marketers** → quick inspiration for viral topics SEO/hashtag research** → discover high-performing keywords Social media teams** → automated trend reporting ⚙️ How It Works – Step by Step 1. Trigger Node:** Manual Trigger Entry point of the workflow. → Can later be replaced with a Cron or Webhook trigger to run automatically. 2. API Call – YouTube Node:** HTTP Request Calls the YouTube Data API v3 with: chart=mostPopular regionCode=DE maxResults=50 Returns a list of trending videos in Germany, including title, channel, views, likes, comments, and tags. 3. Split Items Node:** Split Out Splits the API response (items[]) into individual items, so each video is processed separately. 4. Context & KPIs Node:** Set Extracts key fields: title, channel, publishedAt views, likes, comments Calculates: engagementRate = (likes + comments) / (views + 1) Why? Looking at views alone is misleading. Engagement rate reveals which videos truly resonate with the audience. 5. Ranking & Limit Node:** Item Lists Sorts videos by highest engagement rate (descending). Limits results to the Top 20 videos. Why? This reduces noise and focuses only on the most relevant trends. 6. Collect Tags Node:** Aggregate Collects all snippet.tags from the top videos. Merges them into a single keyword list. 7. Keyword Summary Node:** Summarize Concatenates all collected tags into one string. Result: A compact hashtag/keyword list → ready to use for: Content ideas SEO/hashtag strategies Social media planning 📈 Why This Workflow Is Useful Automated trend analysis**: no need to manually browse YouTube. Quality focus**: uses engagement rate, not just views. Reusable**: results can be: stored in Google Sheets or Airtable, sent to Slack/Telegram, or used in a dashboard. 🚀 Possible Extensions Cron Trigger** → run daily for automated reports. Notifier** → send results directly to Slack, Discord, or Telegram. Storage** → save trends in a database for historical analysis. AI Node** → use GPT to summarize trends into “3 key insights of the day.” ✅ Conclusion With a few smartly combined nodes, this workflow: fetches external API data (YouTube), cleans and enriches it, calculates qualitative KPIs, and delivers actionable trend insights. Perfect as a community showcase or a practical tool for creators and marketers.

Tagged with: , , , ,

Take data from website form via webhook and save data into Google Sheets document!

This workflow integrates HetrixTools with WhatsApp via the GOWA API to automate notifications about server monitoring events. It distinguishes between Uptime Monitoring and Resource Usage Monitoring events, formats the message accordingly, and sends it to a WhatsApp number using the GOWA WhatsApp REST API. It's especially useful for DevOps, sysadmins, or teams who need real-time server alerts delivered via WhatsApp. ⚙️ Setup Instructions Set up HetrixTools: Create a HetrixTools account at https://hetrixtools.com/register Create your Uptime Monitors and/or enable Resource Usage Monitoring for your servers. Go to your HetrixTools contact settings and add the n8n Webhook URL provided by the workflow. Make sure to select this contact in your monitor’s alert settings. Configure n8n Webhook: Set the Webhook node to HTTP method: POST Ensure it is accessible via a public URL (you can use n8n Cloud, reverse proxy, or tunnel like ngrok for testing). Customize WhatsApp Message: The workflow includes a conditional branch to check whether the event is a Resource Usage alert or an Uptime alert. Each branch contains editable text nodes for customizing the WhatsApp message content. Set up GOWA WhatsApp API: Make sure your GOWA instance is running and accessible. Create necessary credentials (API key, base URL, etc.). In n8n, add the credentials and fill in the sendChatPresence and sendText nodes accordingly. Deploy the Workflow: Save and activate the workflow. Trigger a test alert from HetrixTools to verify if messages are received on WhatsApp. 🧱 Prerequisites An active HetrixTools account with Uptime Monitors or Resource Usage Monitoring enabled. A publicly accessible instance of n8n with Webhook node enabled. Access to a running and configured GOWA (WhatsApp REST API) server. Required credentials configured in n8n for GOWA (API key, URL, phone number, etc.).

Auto-Log WhatsApp Inbound Messages to Vtiger CRM Leads (with WhatsAppLog) Description 🔥 A Game-Changer for CRM Logging! Automatically Log WhatsApp Inbound Messages to Vtiger and Link to Leads 💬⚡ ⚠️ This Workflow Requires Community Nodes & a Self-Hosted n8n Instance > This template uses a custom community node: > * n8n-nodes-vtiger-crm > ✅ No need for an Evolution API node — webhook is used instead. 🔧 How to Install Community Nodes Go to Settings → Community Nodes Click Install Node Add this: n8n-nodes-vtiger-crm Restart n8n if prompted. 💬 Automatically Log WhatsApp Inbound Messages in Vtiger CRM Overview This workflow listens for inbound WhatsApp messages via Evolution API Webhook, filters out outbound and group messages, and logs the message in the custom WhatsAppLog module in Vtiger. If the sender is not in CRM, it creates a new lead and links the message. 🔄 What This Workflow Does 📩 Listens to WhatsApp inbound messages via webhook 🚫 Filters out group and outbound messages 🔍 Looks up existing lead by phone 🆕 Creates a new lead if not found 🧾 Logs the message in the WhatsAppLog module 🔗 Relates message to corresponding lead 🔗 Evolution API Webhook Configuration Open your Evolution API dashboard Go to Events → Webhook Enable Webhook Set the Webhook URL to your n8n webhook path: https://your-n8n-domain/webhook/whatsAppListen Enable only the event: ✅ MESSAGES_UPSERT Disable all other events to avoid unnecessary triggers This ensures only inbound WhatsApp messages are pushed to n8n. > No need to use the Evolution API node in n8n. All communication is triggered via webhook. 📸 Visual Preview 🧩 Workflow Canvas > Full view of the automation steps in n8n 💬 WhatsApp Message Capture > A sample inbound message sent to your WhatsApp number 🛠️ Setup Instructions 1. Vtiger CRM Setup Ensure the Leads module has phone fields (phone or mobile) Create a custom module WhatsAppLog (if not already present) Connect your Vtiger CRM API credentials to n8n 2. Webhook Setup Follow the Webhook Configuration steps above for Evolution API Make sure your n8n instance is publicly accessible 3. Workflow Customization Update field mapping inside the Set and Log nodes Adjust the assigned_user_id or custom fields as needed 👥 Who Is This For? CRM admins managing WhatsApp communication Sales teams tracking lead interactions in Vtiger Support teams logging WhatsApp tickets Businesses using Evolution API to receive WhatsApp messages 🔐 Credentials Required ✅ Vtiger CRM API ❌ No Evolution API credentials needed inside workflow (webhook-only) 🏷 Tags vtiger, whatsapp, crm automation, inbound message logging, evolution api, whatsapp crm integration, n8n template, community nodes, lead management, self-hosted n8n, customer communication, no-code crm, webhook

Greetings! If you're in need of a quick and dirty cache that doesn't need anything other than the current version of N8N, boy do I have a dodgy script for you to try! Presenting a simple template for a cache layer using the new N8N Tables Beta! This flow can easily be adapted to meet your home lab or enterprise needs by swapping out the n8n tables nodes with a external database like redis or even a google sheet if one was so inclined. Why Would You Want This? It's simple really, ever had your flow crash because one of the API's you're using has a rate limit less than the 10,000 GET requests you're throwing at it per second (yawn). Well caching can help by adding a small buffer on your side if the data is not likely to change between requests. Simply add a call to this flow to check the cache and if there's nothing there it will throw a error which you can detect and respond to by grabbing fresh data from the API. How This Flow Works This flow does three simple steps in order. Check what you want to do to the cache table, read or write. If Reading, lookup the data | If writing, write the data. If Reading, validate and return | If writing, just return data written for chaining. This subflow will return the JSON.parse() representation of the string currently stored at the key in the cache table. This will be the same value written by the cache write input to this node if it has not expired. If no value is found in the cache table for the input key, then a error is thrown. Listen for this error by setting your error response mode to be {On Error: "Continue (Using Error Output)"} in the node settings. This is your signal to "refresh" the cache by writing a new value to the cache. Inputs Action Read Cache "cacheKey": {any string} Action Write Cache "cacheKey": {any string}, "trueToWrite": true, "writeValue": {any value including null. You are limited to data size of the table string field so don't stuff 20MB of JSON here.}, "writeTTLms": {optional, any number above 0 as milliseconds. Defaults to 10000} Setup Ok onto the good bit, how to set this up locally for yourself. This flow Requires the Beta version of N8N Tables to function, so update if you are running a older version. You will need a table called "cache" <- All lowercase. That table will need the following columns, again all lowercase: key: string ttl: datetime value: string Once you create this table, download, import, or copy paste the flow into your N8N. Got to every "table" node in the flow and update the settings of the node to point to your newly created table (Be sure to press the "refresh" icon in the node configuration menu to ensure you're binding to the correct columns in the table. It should appear after you update the table. It's small so keep a eye out). How to Use Call this flow via the Execute Sub-Flow node with the specified inputs. (Optional) You can also "activate" this flow to enable hourly cleaning of the cache table to help keep data sizes down. This is a example for a quick cache that can not / should not hold onto a large amount of data, be sure to pay attention to the current 50MB limit of tables as writing lots of large data blocks will result in limits being hit. Quick FAQ Why is this a Example not a proper cache? Good Question, glad you asked. This flow is "good enough" for a lot of simple usecases and should be replaced with a more robust caching solution when possible for better performance and memory is going to become a bottleneck. If you're just checking the weather API for yourself and a few friends to serve on your test app, this will be fine. If you're trying to create the next twitter (now called X) where there's gigs of data moving at any second, and you need a large cache to make sure your database doesn't go down, perhaps consider not using a N8N flow for that purpose. Ok so when should I use this then? Well like it was mentioned above, when you have relatively small amounts of data to store and it's not likely to change very often, then this flow should solve your problem. Quick examples of things to cache include: Checking the weather once daily and storing it. Scraping a webstore to check for a daily price of a product you're looking to buy once it's on sale. Checking google trends to see if your company is trending right now. Those examples seem odd, why'd you choose those? Because Caching is one of those hard things in computer science that no one really gets right "cache invalidation, naming things, and off-by-1 errors". Caching should be done on a case by case basis really. For example; the author of this workflow uses it behind some webhook flows for data that takes a long time to grab from the database but only changes 2-5 times a day. Do I have to do things the way you did? No? This is a example of something I threw together in a afternoon to solve a real problem I had. N8N is very flexible and this happened to work out for me. If you don't like the way the example names things or implements its cache invalidation: try things yourself and experiment, you may find that this example will solve your problems by itself without being overly complex. Only you know what will and wont work to solve your problems.

Summary This is a minimal template that focuses on how to integrate n8n and Home Assistant for event-based triggering from Home Assistant using the AppDaemon addon to call a webhook node. Problem Solved: There is no Home Assistant trigger node in n8n. You can poll the Home Assistant API on a schedule. A more efficient work around is to use the AppDaemon addon to create a listener app within Home Assistant. When the listener detects the event, it is subscribed to. An AppDaemon app is initiated that calls a N8N webhook passing the the event data to the workflow. AppDaemon runs python code. The template contains a sticky note. Within the sticky note there is a code example (repeated below) for a AppDeamon app, the code contains annotated instructions on configuration. Steps: Install the AppDaemon Add-on A. Open Home Assistant. In your Home Assistant UI, go to Settings - Add-ons (or Supervisor - Add-on Store, depending on your version). B. Search and Install. In the Add-on Store, search for "AppDaemon 4". Click on the result and then the Install button to start the installation. C. Start the Add-on. Once installed, open the AppDaemon 4 add-on page. Click Start to launch AppDaemon. (Optional but recommended) Enable Start on boot and Watchdog options to make sure AppDaemon starts automatically and restarts if it crashes. D. Verify Installation. Check the logs in the AppDaemon add-on page to ensure it’s running without issues. No need to set access tokens or Home Assistant URL manually; the add-on is pre-configured to connect with your Home Assistant. E. Configure AppDaemon. After installation, a directory named appdaemon will appear inside your Home Assistant config directory (/config/appdaemon/). Inside, you’ll find a file called appdaemon.yaml. For most uses, the default configuration is fine, but you can customize it as needed. Create the AppDaemon App. F. Prepare Your Apps Directory. Inside /config/appdaemon/, locate or create an apps folder. Path: /config/appdaemon/apps/. G. Create a Python App Inside the apps folder, create a new Python file (example: n8n_WebHook.py). Open the file in an editor and paste the example code into the file. import appdaemon.plugins.hass.hassapi as hass import requests import json class EventTon8nWebhook(hass.Hass): """ AppDaemon app that listens for Home Assistant events and forwards them to n8n webhook """ def initialize(self): """ Initialize the event listener and configure webhook settings """ EDIT: Replace 'your_event_name' with the actual event you want to listen for Common HA events: 'state_changed', 'call_service', 'automation_triggered', etc. self.target_event = self.args.get('target_event', 'your_event_name') EDIT: Set your n8n webhook URL in apps.yaml or replace the default here self.webhook_url = self.args.get('webhook_url', 'n8n_webhook_url') EDIT: Optional - set timeout for webhook requests (seconds) self.webhook_timeout = self.args.get('webhook_timeout', 10) EDIT: Optional - enable/disable SSL verification self.verify_ssl = self.args.get('verify_ssl', True) Set up the event listener self.listen_event(self.event_handler, self.target_event) self.log(f"Event listener initialized for event: {self.target_event}") self.log(f"Webhook URL configured: {self.webhook_url}") def event_handler(self, event_name, data, kwargs): """ Handle the triggered event and forward to n8n webhook Args: event_name (str): Name of the triggered event data (dict): Event data from Home Assistant kwargs (dict): Additional keyword arguments from the event """ try: Prepare payload for n8n webhook payload = { 'event_name': event_name, 'event_data': data, 'event_kwargs': kwargs, 'timestamp': self.datetime().isoformat(), 'source': 'home_assistant_appdaemon' } self.log(f"Received event '{event_name}' - forwarding to n8n") self.log(f"Event data: {data}") Send to n8n webhook self.send_to_n8n(payload) except Exception as e: self.log(f"Error handling event {event_name}: {str(e)}", level="ERROR") def send_to_n8n(self, payload): """ Send payload to n8n webhook Args:payload (dict): Data to send to n8n """ try: headers = { 'Content-Type': 'application/json', #EDIT assume header authentication parameter and value below need to match what is set in the credential used in the node. 'CredName': 'credValue', #set to what you set up as a credential for the webhook node } response = requests.post( self.webhook_url, json=payload, headers=headers, timeout=self.webhook_timeout, verify=self.verify_ssl ) response.raise_for_status() self.log(f"Successfully sent event to n8n webhook. Status: {response.status_code}") EDIT: Optional - log response from n8n for debugging if response.text: self.log(f"n8n response: {response.text}") except requests.exceptions.Timeout: self.log(f"Timeout sending to n8n webhook after {self.webhook_timeout}s", level="ERROR") except requests.exceptions.RequestException as e: self.log(f"Error sending to n8n webhook: {str(e)}", level="ERROR") except Exception as e: self.log(f"Unexpected error sending to n8n: {str(e)}", level="ERROR") H. Register Your App In the same apps folder, locate or create a file named apps.yaml. Add an entry to register your app: EventTon8nWebhook: module: n8n_WebHook class: EventTon8nWebhook Module should match your Python filename (without the .py). class matches the class name inside your Python file, i.e. EventTon8nWebHook I. Reload AppDaemon In Home Assistant, return to the AppDaemon 4 add-on page and click Restart. Watch the logs; you should see a log entry from your app confirming it is initialised running. Set Up n8n J. In your workflow create a webhook trigger node as the first node, or use the template as your starting point. Ensure the webhook URL (production or test) is correctly copied to the python code. If you are using authentication this needs a credential creating for the webhook. The example uses header auth. Naturally this should match what is in the code. For security likely better to put the credentials in a "secrets.yaml" file rather than hard code like this demo. Execute the workflow or activate if using the production webhook. Either wait for an event in Home Assistant or one can be manually triggered from the developer settings page, event tab. K. Finally develop your workflow to process the received event per your use case. See the Home Assistant docs on events for details of the event types you can subscribe to: Home Assistant Events

How to secure GET Webhooks? What are webhooks? Webhooks are special URLs that instantly trigger workflows when they receive an incoming HTTP request (like GET or POST). They're perfect for connecting external tools to n8n in real time. 🔐 Why webhooks should be protected Unprotected webhooks are publicly accessible on the internet — anyone with the link can trigger your workflow. This can lead to spam, unwanted requests, or even data loss. ✅ Best Practice: Use built-in Authentication n8n provides native authentication options for webhook nodes: Basic Auth Header Auth JWT Auth These methods are highly recommended if supported by your external app or service. You can find them in the “Authentication” dropdown of the webhook node. 🛠️ When to use THIS SETUP Sometimes, external tools don’t support custom headers or advanced auth methods — for example: A button click in Google Sheets A link shared via email or chat with a trusted partner IoT devices or basic web apps In those cases, you can protect a webhook by adding a secret query parameter (e.g. ?secret=abc123xyz456...) and validating it with an IF node at the start of your workflow. This way, only those requests with the secret can trigger the core elements of your workflow. It's a simple yet powerful way to secure GET-based workflows. Only use if better methods aren't available.