Quick overview This workflow accepts an article brief via webhook, routes it through a three-stage LLM pipeline to research, draft, and review HTML content, optionally generates a featured image with Google Imagen, then creates a WordPress draft post with tags and Rank Math SEO metadata and sends an optional Slack notification. How it works Receives a POST webhook request with a required prompt (and optional category, tone, and style overrides) and optionally validates a Bearer token. A researcher agent calls the LLM sub-workflow to produce a structured JSON outline, including title, H2 sections, tags, focus keyword, and image subject. Optionally starts the generation of a 16:9 featured image in parallel using Imagen 4 and the outline's image subject. The default option for whether this is enabled (set in CONFIG), can be overridden per run in the request prompt. Optionally fetches recent published WordPress posts and selects up to five relevant URLs to use as internal links. A writer agent drafts the full HTML article body based on the outline (and internal links), tone guide, and style guide from CONFIG.
Tags
Related workflows
See all Slack→Monitor Domains & IPs on AbuseIPDB Blacklist with Slack Alerts
⚙ How It Works The automated blacklist monitor is designed to be a proactive, not reactive, tool. Here is the high-level process: Scheduled Checks: At regular intervals (e.g., every 30 minutes or every hour), a monitoring script or service sends a request to a list of predefined DNS blacklists (DNSBLs) and real-time blackhole lists (RBLs). Lookup Queries: For each check, the system performs a lookup query for our specified domains and IP addresses against the various blacklists. It essentially asks, "Is our-ip-address.com on your list?" Status Evaluation: The blacklist service responds with a status: either the asset is clean or it is listed. Alerting Mechanism: If a new listing is detected, the system immediately triggers a notification. This alert contains key information like the asset that was blacklisted (domain or IP), the specific blacklist it was found on (e.g., Spamhaus), and the time of detection. Status Logging: The status of each asset (clean or listed) is logged in a central dashboard. This allows us to track the history of an IP or domain, see when a listing occurred, and when it was resolved. Setup Steps Follow these steps to set up the automated blacklist monitor. S
Monitor Email Data Breaches with HIBP API and Send Slack Alerts
How It Works: The 5-Node Security Flow This workflow efficiently performs a scheduled data breach scan. 1. Scheduled Check (Cron Node) This is the workflow's trigger. It schedules the workflow to run at a specific, regular interval. Function:** Continuously runs on a set schedule, for example, every Monday morning. Process:* The *Cron** node automatically initiates the workflow, ensuring routine data breach scans are performed without manual intervention. 2. List Emails to Check (Code Node) This node acts as your static database, defining which email addresses to monitor for breaches. Function:** Stores a list of email addresses from your team or customers in a single, easy-to-update array. Process:** It configures the list of emails that are then processed by the subsequent nodes. This makes it simple to add or remove addresses as needed. 3. Query HIBP API (HTTP Request Node) This node connects to the HaveIBeenPwned (HIBP) API to check for breaches. Function:** Queries the HIBP API for each email address on your list. Process:** It sends a request to the HIBP API. The API responds with a list of data breaches that the email was found in, if any. 4. Is Breached? (If Node) This is t
Monitor Security Logs for Failed Login Attempts with Slack Alerts
How It Works: The 5-Node Anomaly Detection Flow This workflow efficiently processes logs to detect anomalies. Scheduled Check (Cron Node): This is the primary trigger. It schedules the workflow to run at a defined interval (e.g., every 15 minutes), ensuring logs are routinely scanned for suspicious activity. Fetch Logs (HTTP Request Node): This node is responsible for retrieving logs from an external source. It sends a request to your log API endpoint to get a batch of the most recent logs. Count Failed Logins (Code Node): This is the core of the detection logic. The JavaScript code filters the logs for a specific event ("login_failure"), counts the total, and identifies unique IPs involved. This information is then passed to the next node. Failed Logins > Threshold? (If Node): This node serves as the final filter. It checks if the number of failed logins exceeds a threshold you set (e.g., more than 5 attempts). If it does, the workflow is routed to the notification node; if not, the workflow ends safely. Send Anomaly Alert (Slack Node): This node sends an alert to your team if an anomaly is detected. The Slack message includes a summary of the anomaly, such as the number of fai