@n8n/instance-ai 1.1.0 → 1.2.1

package/dist/tools/best-practices/guides/form-input.js

@@ -1,166 +0,0 @@
-"use strict";
-Object.defineProperty(exports, "__esModule", { value: true });
-exports.getDocumentation = getDocumentation;
-function getDocumentation() {
-    return `# Best Practices: Form Input Workflows
-
-## Workflow Design
-
-### Critical: Always Store Raw Form Data
-
-ALWAYS store raw form responses to a persistent data storage destination even if the primary purpose of the workflow is
-to trigger another action (like sending to an API or triggering a notification). This allows users to monitor
-form responses as part of the administration of their workflow.
-
-Required storage destinations include:
-- Google Sheets node
-- Airtable node
-- n8n Data Tables
-- PostgreSQL/MySQL/MongoDB nodes
-- Any other database or spreadsheet service
-
-IMPORTANT: Simply using Set or Merge nodes is NOT sufficient. These nodes only transform data in memory - they do not
-persist data. You must use an actual storage node (like Google Sheets, Airtable, or Data Tables) to write the data.
-
-Storage Requirements:
-- Store the un-edited user input immediately after the form steps are complete
-- Do not store only a summary or edited version of the user's inputs - store the raw data
-- For single-step forms: store immediately after the form trigger
-- For multi-step forms: store immediately after aggregating all steps with Set/Merge nodes
-- The storage node should appear in the workflow right after data collection/aggregation
-
-## Message Attribution
-
-n8n forms attach the attribution "n8n workflow" to messages by default - you must disable this setting which will
-often be called "Append n8n Attribution" for the n8n form nodes, add this setting and set it to false.
-
-## Multi-Step Forms
-
-Build multi-step forms by chaining multiple Form nodes together. Each Form node represents a page or step in your form
-sequence. Use the n8n Form Trigger node to start the workflow and display the first form page to the user.
-
-## Data Collection & Aggregation
-
-Collect and merge all user responses from each form step before writing to your destination (e.g., Data Table). Use
-Set or Merge nodes to combine data as needed. Make sure your JSON keys match the column names in your destination for
-automatic mapping.
-
-## Conditional Logic & Branching
-
-Use IF or Switch nodes to direct users to different form pages based on their previous answers. This enables dynamic
-form flows where the path changes based on user input, creating personalized form experiences.
-
-## Dynamic Form Fields
-
-For forms that require dynamic options (e.g., dropdowns populated from an API or previous step), generate the form
-definition in a Code node and pass it to the Form node as JSON. You can define forms using JSON for dynamic or
-conditional fields, and even generate form fields dynamically using a Code node if needed.
-
-## Input Validation
-
-Validate user input between steps to ensure data quality. If input is invalid, loop back to the relevant form step with
-an error message to guide the user to correct their submission. This prevents bad data from entering your system.
-
-## Recommended Nodes
-
-### n8n Form Trigger (n8n-nodes-base.formTrigger)
-
-Purpose: Starts the workflow and displays the first form page to the user
-
-Pitfalls:
-
-- Use the Production URL for live forms; the Test URL is for development and debugging only
-- Ensure the form trigger is properly configured before sharing URLs with users
-
-### n8n Form (n8n-nodes-base.form)
-
-Purpose: Displays form pages in multi-step form sequences
-
-Pitfalls:
-
-- Each Form node represents one page/step in your form
-- You can define forms using JSON for dynamic or conditional fields
-- Generate form fields dynamically using a Code node if needed for complex scenarios
-
-### Storage Nodes
-
-Purpose: Persist raw form data to a storage destination, preference should be for built-in n8n tables
-but use the most applicable node depending on the user's request.
-
-Required nodes (use at least one):
-- Data table (n8n-nodes-base.dataTable): Built-in n8n storage for quick setup - preferred
-- Google Sheets (n8n-nodes-base.googleSheets): Best for simple spreadsheet storage
-- Airtable (n8n-nodes-base.airtable): Best for structured database with relationships
-- Postgres (n8n-nodes-base.postgres) / MySQL (n8n-nodes-base.mySql) / MongoDB (n8n-nodes-base.mongoDb): For production database storage
-
-Pitfalls:
-
-- Every form workflow MUST include a storage node that actually writes data to a destination
-- Set and Merge nodes alone are NOT sufficient - they only transform data in memory
-- The storage node should be placed immediately after the form trigger (single-step) or after data aggregation (multi-step)
-
-### Code (n8n-nodes-base.code)
-
-Purpose: Processes form data, generates dynamic form definitions, or implements custom validation logic
-
-### Edit Fields (Set) (n8n-nodes-base.set)
-
-Purpose: Aggregates and transforms form data between steps (NOT for storage - use a storage node)
-
-### Merge (n8n-nodes-base.merge)
-
-Purpose: Combines data from multiple form steps into a single dataset (NOT for storage - use a storage node)
-
-Pitfalls:
-
-- Ensure data from all form steps is properly merged before writing to destination
-- Use appropriate merge modes (append, merge by key, etc.) for your use case
-- Remember: Merge prepares data but does not store it - add a storage node after Merge
-
-### If (n8n-nodes-base.if)
-
-Purpose: Routes users to different form pages based on their previous answers
-
-### Switch (n8n-nodes-base.switch)
-
-Purpose: Implements multi-path conditional routing in complex forms
-
-Pitfalls:
-
-- Include a default case to handle unexpected input values
-- Keep routing logic clear and maintainable
-
-## Common Pitfalls to Avoid
-
-### Missing Raw Form Response Storage
-
-When building n8n forms it is recommended to always store the raw form response to some form of data storage (Googlesheets, Airtable, etc)
-for administration later. It is CRITICAL if you create a n8n form node that you store the raw output with a storage node.
-
-### Data Loss in Multi-Step Forms
-
-Aggregate all form step data using Set/Merge nodes before writing to your destination. Failing to merge data from multiple steps
-can result in incomplete form submissions being stored. After merging, ensure you write the complete dataset to a storage node.
-
-### Poor User Experience
-
-Use the Form Ending page type to show a completion message or redirect users after submission.
-Without a proper ending, users may be confused about whether their submission was successful.
-
-### Invalid Data
-
-Implement validation between form steps to catch errors early. Without validation, invalid data can
-propagate through your workflow and corrupt your destination data.
-
-### Complex Field Generation
-
-When generating dynamic form fields, ensure the JSON structure exactly matches what the Form
-node expects. Test thoroughly with the Test URL before going live.
-
-### Mapping Errors
-
-When writing to Google Sheets or other destinations, ensure field names match exactly. Mismatched names
-will cause data to be written to wrong columns or fail entirely.
-`;
-}
-//# sourceMappingURL=form-input.js.map

package/dist/tools/best-practices/guides/form-input.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"form-input.js","sourceRoot":"","sources":["../../../../src/tools/best-practices/guides/form-input.ts"],"names":[],"mappings":";;AAAA,4CAiKC;AAjKD,SAAgB,gBAAgB;IAC/B,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA+JP,CAAC;AACF,CAAC"}

package/dist/tools/best-practices/guides/notification.d.ts

@@ -1 +0,0 @@
-export declare function getDocumentation(): string;

package/dist/tools/best-practices/guides/notification.js

@@ -1,128 +0,0 @@
-"use strict";
-Object.defineProperty(exports, "__esModule", { value: true });
-exports.getDocumentation = getDocumentation;
-function getDocumentation() {
-    return `# Best Practices: Notification Workflows
-
-## Workflow Design
-
-Structure notification workflows in a clear sequence. Keep each part modular with nodes dedicated to specific purposes.
-
-\`\`\`mermaid
-graph LR
-    A[Trigger] --> B[Data Retrieval/Processing]
-    B --> C[Condition Check]
-    C --> D[Notification Action]
-    D --> E[Post-Notification: logging/tracking]
-\`\`\`
-
-Choose between event-based triggers (webhooks, form submissions, CRM events) for immediate notifications or scheduled triggers (Cron) for periodic condition monitoring.
-
-CRITICAL: Multi-channel notifications should branch from a single condition check to multiple notification nodes in parallel, not duplicate the entire workflow. This enables easy extension and maintenance.
-
-Example pattern:
-\`\`\`mermaid
-graph LR
-    A[Webhook/Schedule Trigger] --> B[Fetch Data]
-    B --> C[If: threshold exceeded]
-    C -->|true| D[Email]
-    C -->|true| E[Slack]
-    C -->|true| F[SMS]
-    C -->|false| G[End/Log]
-\`\`\`
-Result: Single workflow handles all channels efficiently with consistent logic
-
-## Condition Logic & Filtering
-
-Use IF nodes for simple checks without code. For complex conditions (multiple fields, array filtering), use Code nodes to script the logic and filter items that need alerts.
-
-Always include empty notification prevention - check that alert-worthy items exist (items.length > 0) before proceeding to notification nodes. Route the false branch to end the workflow or log "no alert needed".
-
-## Message Construction
-
-Use expressions to inject dynamic data into messages. The expression \`{{ $json.fieldName }}\` pulls data from input items.
-
-Format messages appropriately for each channel:
-- Email: Support HTML or plain text, use clear subject lines
-- Slack: Use markdown-like formatting, \\n for newlines
-- SMS: Keep concise due to character limits, plain text only
-
-## Alert Management
-
-Consider alert aggregation - send one message listing multiple items rather than individual alerts.
-
-Add logging nodes to track sent notifications for audit trails and duplicate prevention. Consider using error handling paths with Continue on Fail settings for redundancy.
-
-## Recommended Nodes
-
-### Trigger Nodes
-
-**Service-specific triggers** (e.g., n8n-nodes-base.googleSheetsTrigger, n8n-nodes-base.crmTrigger):
-- Purpose: Direct integration with specific services for event-based notifications
-- Use cases: New row in Google Sheets, CRM record updates
-- When to use: When specific trigger node is available
-
-**Webhook** (n8n-nodes-base.webhook):
-- Purpose: Event-based notifications triggered by external systems
-- Use cases: Form submissions, CRM events, API webhooks
-- When to use: When there is no dedicated trigger node and external service supports webhooks
-
-**Schedule Trigger** (n8n-nodes-base.scheduleTrigger):
-- Purpose: Periodic monitoring and batch notifications
-- Use cases: Daily reports, threshold monitoring, scheduled alerts
-- When to use: For regular checks rather than immediate alerts, or as a polling mechanism when webhooks are not available
-
-**Form Trigger** (n8n-nodes-base.formTrigger):
-- Purpose: User-submitted data triggering notifications
-- Use cases: Contact forms, feedback submissions
-- When to use: For workflows initiated by user input via forms
-
-### Notification Nodes
-
-**Send Email** (n8n-nodes-base.emailSend):
-- Purpose: Detailed alerts with attachments and HTML formatting
-- Use cases: Reports, detailed notifications, formal communications
-- Configuration: SMTP settings, use App Passwords for Gmail
-- Best practice: Use clear subject lines with key information
-
-**Slack** (n8n-nodes-base.slack):
-- Purpose: Team notifications in channels or direct messages
-- Use cases: Team alerts, status updates, incident notifications
-- Configuration: Bot token with chat:write scope, bot must be invited to channel
-- Best practice: Use markdown formatting, channel IDs (starting with C) not names
-
-**Telegram** (n8n-nodes-base.telegram):
-- Purpose: Instant messaging alerts to individuals or groups
-- Use cases: Personal notifications, bot interactions
-- Configuration: Bot token from BotFather
-- Best practice: Use chat ID for direct messages
-
-**Twilio** (n8n-nodes-base.twilio):
-- Purpose: SMS/WhatsApp critical alerts
-- Use cases: High-priority alerts, two-factor authentication, critical incidents
-- Configuration: Account SID, Auth Token, verified phone numbers
-- Best practice: Keep messages concise, use international format (+1234567890)
-
-**HTTP Request** (n8n-nodes-base.httpRequest):
-- Purpose: Custom webhooks (Microsoft Teams, Discord, custom APIs)
-- Use cases: Integration with services without dedicated nodes
-
-### Logic & Processing
-
-**IF** (n8n-nodes-base.if):
-- Purpose: Simple threshold checks and condition routing
-- Use cases: Check if notification criteria met
-- Best practice: Include empty notification prevention (items.length > 0)
-
-**Switch** (n8n-nodes-base.switch):
-- Purpose: Route notifications based on severity/type
-- Use cases: Different channels for different alert levels
-- Best practice: Always define Default case for unexpected values
-
-**Set** (n8n-nodes-base.set):
-- Purpose: Prepare alert messages and structure data
-- Use cases: Format notification content, add metadata
-- Best practice: Use to centralize message construction logic
-`;
-}
-//# sourceMappingURL=notification.js.map

package/dist/tools/best-practices/guides/notification.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"notification.js","sourceRoot":"","sources":["../../../../src/tools/best-practices/guides/notification.ts"],"names":[],"mappings":";;AAAA,4CA2HC;AA3HD,SAAgB,gBAAgB;IAC/B,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAyHP,CAAC;AACF,CAAC"}

package/dist/tools/best-practices/guides/scheduling.d.ts

@@ -1 +0,0 @@
-export declare function getDocumentation(): string;

package/dist/tools/best-practices/guides/scheduling.js

@@ -1,145 +0,0 @@
-"use strict";
-Object.defineProperty(exports, "__esModule", { value: true });
-exports.getDocumentation = getDocumentation;
-function getDocumentation() {
-    return `# Best Practices: Scheduling Workflows
-
-## Workflow Design
-
-Structure scheduled workflows to perform focused, well-defined tasks.
-
-For recurring tasks, use Schedule Trigger node with clear naming (e.g., "Daily 08:00 Trigger", "Every 6h Cron").
-
-Prevent overlapping executions by ensuring worst-case execution time < schedule interval. For frequent schedules, implement mutex/lock mechanisms using external systems if needed.
-
-## Scheduling Patterns
-
-### Recurring Schedules
-
-Use Schedule Trigger in two modes:
-- **Interval Mode**: User-friendly dropdowns for common schedules (every X minutes, daily at 09:00, weekly on Mondays)
-- **Cron Expression Mode**: Complex patterns using 5-field syntax (m h dom mon dow) with optional seconds field. Example: \`0 9 * * 1\` triggers every Monday at 09:00
-
-Multiple schedules can be combined in single Schedule Trigger node using multiple Trigger Rules. Useful when same logic applies to different timings.
-
-### One-Time Events
-
-For event-relative scheduling, use Wait node to pause workflow until specified time/date.
-
-Note: Cron expressions with specific dates (e.g., \`0 12 22 10 *\` for Oct 22 at 12:00) will repeat annually on that date.
-
-### Conditional Scheduling
-
-PREFER conditional logic over complex cron expressions. Use IF/Switch nodes after Schedule Trigger for runtime conditions:
-- Check if today is last day of month before running monthly reports
-- Skip execution on holidays by checking against a holiday list in a data table
-- Route to "weekday" vs "weekend" processing based on current day
-
-This approach is more readable and maintainable than complex cron patterns.
-
-## Time Zone Handling
-
-When building scheduled workflows:
-- If user specifies a timezone, set it in the Schedule Trigger node's timezone parameter
-- If user mentions times without timezone, use the schedule as specified (instance default will apply)
-- For Wait nodes, be aware they use server system time, not workflow timezone
-
-## Recommended Nodes
-
-### Schedule Trigger (n8n-nodes-base.scheduleTrigger)
-
-Primary node for running workflows on schedule. Supports interval mode for simple schedules and cron mode for complex patterns.
-
-### Wait (n8n-nodes-base.wait)
-
-Pause workflow execution until specified time or duration.
-
-Use Cases:
-- Delay actions relative to events
-- One-off timers per data item
-- Follow-up actions after specific duration
-
-Best Practices:
-- Use n8n Data Tables for waits longer than 24 hours (store scheduled time, check periodically)
-- Avoid wait times longer than 7 days - use a polling pattern instead
-
-### IF (n8n-nodes-base.if)
-
-Add conditional logic to scheduled workflows.
-
-Use Cases:
-- Check date conditions (last day of month using expression: \`{{ $now.day === $now.endOf('month').day }}\`)
-- Skip execution based on external data (e.g., holiday check)
-- Route to different actions conditionally
-
-Best Practices:
-- Enable "Convert types where required" for comparisons
-- Prefer IF nodes over complex cron expressions for readability
-
-### Switch (n8n-nodes-base.switch)
-
-Multiple conditional branches for complex routing.
-
-Use Cases:
-- Different actions based on day of week (e.g., \`{{ $now.weekday }}\` returns 1-7)
-- Time-based routing (morning vs afternoon processing)
-- Multi-path conditional execution
-
-### n8n Data Tables (n8n-nodes-base.n8nTables)
-
-Purpose: Store scheduling state and pending tasks
-
-Use Cases:
-- Track last execution time for catch-up logic
-- Store list of pending one-time tasks with scheduled times
-- Implement custom scheduling queue with polling
-
-Best Practices:
-- Query efficiently with proper filters
-- Clean up completed tasks periodically
-
-## Common Pitfalls to Avoid
-
-### Missed Schedules During Downtime
-
-**Problem**: Scheduled runs missed when n8n instance is down. No automatic catch-up for missed triggers.
-
-**Solution**: Design idempotent workflows with catch-up logic:
-- Store last successful run timestamp in n8n Data Tables
-- On each run, check if enough time has passed since last run
-- Example: For a task that should run once per 24 hours, schedule it every 4 hours but only execute if last run was >20 hours ago
-
-### Overlapping Executions
-
-**Problem**: Next scheduled run starts before previous completes, causing race conditions or resource conflicts.
-
-**Solution**:
-- Increase interval to exceed worst-case execution time
-- Implement mutex/lock using n8n Data Tables (check/set "running" flag at start, clear at end)
-- Add execution check at workflow start
-
-### Wait Node Timezone Confusion
-
-**Problem**: Wait node uses server system time, ignoring workflow timezone setting. Wait until "10:00" may not match expected timezone.
-
-**Solution**:
-- Account for server timezone when setting Wait times
-- Use relative durations (e.g., "wait 2 hours") instead of absolute times when possible
-- Prefer Schedule Trigger for timezone-aware scheduling
-
-### First Execution Timing
-
-**Problem**: First execution after activation doesn't match expected schedule. Activation time affects next run calculation.
-
-**Solution**:
-- Use manual execution for immediate first run if needed
-- Understand that schedule recalculates from activation moment
-
-### Cron Syntax
-
-n8n supports both 5-field and 6-field (with seconds) cron syntax. Use 6 fields if you want to specify seconds (e.g., prefix with 0 for seconds: \`0 0 9 * * *\` for 9 AM daily).
-
-For simple schedules, prefer Interval mode over cron for better readability.
-`;
-}
-//# sourceMappingURL=scheduling.js.map

package/dist/tools/best-practices/guides/scheduling.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"scheduling.js","sourceRoot":"","sources":["../../../../src/tools/best-practices/guides/scheduling.ts"],"names":[],"mappings":";;AAAA,4CA4IC;AA5ID,SAAgB,gBAAgB;IAC/B,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA0IP,CAAC;AACF,CAAC"}

package/dist/tools/best-practices/guides/scraping-and-research.d.ts

@@ -1 +0,0 @@
-export declare function getDocumentation(): string;

package/dist/tools/best-practices/guides/scraping-and-research.js

@@ -1,151 +0,0 @@
-"use strict";
-Object.defineProperty(exports, "__esModule", { value: true });
-exports.getDocumentation = getDocumentation;
-function getDocumentation() {
-    return `# Best Practices: Scraping & Research Workflows
-
-## Performance & Resource Management
-
-Batch requests and introduce delays to avoid hitting API rate limits or overloading target servers. Use Wait nodes and
-batching options in HTTP Request nodes. When 429 rate limiting errors occur due to receiving too many requests,
-implement batching to reduce request frequency or use the "Retry on Fail" feature to automatically handle throttled
-responses.
-
-Workflows processing large datasets can crash due to memory constraints. Use the Split In Batches node to process 200
-rows at a time to reduce memory usage, leverage built-in nodes instead of custom code, and increase execution timeouts
-via environment variables for better resource management.
-
-## Looping & Pagination
-
-Implement robust looping for paginated data. Use Set, IF, and Code nodes to manage page numbers and loop conditions,
-ensuring you don't miss data or create infinite loops. Leverage n8n's built-in mechanisms rather than manual approaches:
-use the $runIndex variable to track iterations without additional code nodes, and employ workflow static data or node
-run indexes to maintain state across loop cycles.
-
-## Recommended Nodes
-
-### HTTP Request (n8n-nodes-base.httpRequest)
-
-Purpose: Fetches web pages or API data for scraping and research workflows
-
-Pitfalls:
-
-- Depending on the data which the user wishes to scrape/research, it maybe against the terms of service to attempt to
-fetch it from the site directly. Using scraping nodes is the best way to get around this
-- Double-check URL formatting, query parameters, and ensure all required fields are present to avoid bad request errors
-- Be aware of 429 rate limiting errors when the service receives too many requests - implement batching or use "Retry on
-Fail" feature
-- Refresh expired tokens, verify API keys, and ensure correct permissions to avoid authentication failures
-
-### SerpAPI (@n8n/n8n-nodes-langchain.toolSerpApi)
-
-Purpose: Give an agent the ability to search for research materials and fact-checking results that have been retrieved
-from other sources.
-
-### Perplexity (n8n-nodes-base.perplexityTool)
-
-Purpose: Give an agent the ability to search utilising Perplexity, a powerful tool for finding sources/material for
-generating reports and information.
-
-### HTML Extract (n8n-nodes-base.htmlExtract)
-
-Purpose: Parses HTML and extracts data using CSS selectors for web scraping
-
-Pitfalls:
-
-- Some sites use JavaScript to render content, which may not be accessible via simple HTTP requests. Consider using
-browser automation tools or APIs if the HTML appears empty
-- Validate that the CSS selectors match the actual page structure to avoid extraction failures
-
-### Split Out (n8n-nodes-base.splitOut)
-
-Purpose: Processes lists of items one by one for sequential operations
-
-Pitfalls:
-- Can cause performance issues with very large datasets - consider using Split In Batches instead
-
-### Loop Over Items (Split in Batches) (n8n-nodes-base.splitInBatches)
-
-Purpose: Processes lists of items in batches to manage memory and performance
-
-Pitfalls:
-- Ensure proper loop configuration to avoid infinite loops or skipped data. The index 0
-(first connection) of the loop is treated as the done state, while the index 1 (second connection)
-is the connection that loops.
-- Use appropriate batch sizes (e.g., 200 rows) to balance memory usage and performance
-
-### Edit Fields (Set) (n8n-nodes-base.set)
-
-Purpose: Manipulates data, sets variables for loop control and state management
-
-### Code (n8n-nodes-base.code)
-
-Purpose: Implements custom logic for complex data transformations or pagination
-
-Pitfalls:
-
-- Prefer built-in nodes over custom code to reduce memory usage and improve maintainability
-- Avoid processing very large datasets in a single code execution - use batching
-
-### If (n8n-nodes-base.if)
-
-Purpose: Adds conditional logic for error handling, loop control, or data filtering
-
-Pitfalls:
-- Validate expressions carefully to avoid unexpected branching behavior
-
-### Wait (n8n-nodes-base.wait)
-
-Purpose: Introduces delays to respect rate limits and avoid overloading servers
-
-### Data Tables (n8n-nodes-base.dataTable)
-
-Purpose: Stores scraped data in n8n's built-in persistent data storage
-
-### Google Sheets (n8n-nodes-base.googleSheets)
-
-Purpose: Stores scraped data in spreadsheets for easy access and sharing
-
-### Microsoft Excel 365 (n8n-nodes-base.microsoftExcel)
-
-Purpose: Stores scraped data in Excel files for offline analysis
-
-### Airtable (n8n-nodes-base.airtable)
-
-Purpose: Saves structured data to a database with rich data types and relationships
-
-### AI Agent (@n8n/n8n-nodes-langchain.agent)
-
-Purpose: For research, summarization, and advanced data extraction. AI agents can autonomously gather information
-from websites, analyze content, and organize findings into structured formats, integrating tools for web scraping,
-content analysis, and database storage
-
-### Scraping Nodes
-
-- Phantombuster (n8n-nodes-base.phantombuster)
-- Apify (use HTTP Request or community node)
-- BrightData (use HTTP Request or community node)
-
-Purpose: If the user wishes to scrap data from sites like LinkedIn, Facebook, Instagram, Twitter/X, Indeed, Glassdoor
-or any other service similar to these large providers it is better to use a node designed for this. The scraping
-nodes provide access to these datasets while avoiding issues like rate limiting or breaking terms of service for
-sites like these.
-
-## Common Pitfalls to Avoid
-
-Bad Request Errors: Double-check URL formatting, query parameters, and ensure all required fields are present to
-avoid 400 errors when making HTTP requests.
-
-Rate Limits: Use batching and Wait nodes to avoid 429 errors. When the service receives too many requests, implement
-batching to reduce request frequency or use the "Retry on Fail" feature.
-
-Memory Issues: Avoid processing very large datasets in a single run; use batching and increase server resources if
-needed. Use Split In Batches node to process 200 rows at a time, leverage built-in nodes instead of custom code, and
-increase execution timeouts via environment variables.
-
-Empty or Unexpected Data: Some sites use JavaScript to render content, which may not be accessible via simple HTTP
-requests. Standard HTTP and HTML parsing nodes fail because sites load data asynchronously via JavaScript, leaving the
-initial HTML empty of actual content. Web scraping nodes can be used to avoid this.
-`;
-}
-//# sourceMappingURL=scraping-and-research.js.map

package/dist/tools/best-practices/guides/scraping-and-research.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"scraping-and-research.js","sourceRoot":"","sources":["../../../../src/tools/best-practices/guides/scraping-and-research.ts"],"names":[],"mappings":";;AAAA,4CAkJC;AAlJD,SAAgB,gBAAgB;IAC/B,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAgJP,CAAC;AACF,CAAC"}

package/dist/tools/best-practices/guides/triage.d.ts

@@ -1 +0,0 @@
-export declare function getDocumentation(): string;