Integrate Postgres with 500+ apps and services

query data from two different databases handle and unify in a single return

Read data from Postgres Converting it to XLS Save it to disk

The template allows to make Dropcontact batch requests up to 250 requests every 10 minutes (1500/hour). Valuable if high volume email enrichment is expected. Dropcontact will look for email & basic email qualification if first_name, last_name, company_name is provided. +++++++++++++++++++++++++++++++++++++++++ Step 1: Node "Profiles Query" Connect your own source (Airtable, Google Sheets, Supabase,...) the template is using Postgres by default. Note I: Be careful your source is only returning a maximum of 250 items. Note II: The next node uses the next variables, make sure you can map these from your source file: first_name last_name website (company_name would work too) full_name (see note) Note III: This template is using the Dropcontact Batch API, which works in a POST & GET setup. Not a GET request only to retrieve data, as Dropcontact needs to process the batch data load properly. +++++++++++++++++++++++++++++++++++++++++ Step 2: Node "Data Transformation" Will transform the input variables in the proper json format. This json format is expected from the Dropcontact API to make a batch request. "full_name" is being used as a custom identifier to update the returned email to the proper contact in your source database. To make things easy, use a unique identiefer in the full_name variable. +++++++++++++++++++++++++++++++++++++++++ Step3: Node: "Bulk Dropcontact Requests". Enter your Dropcontact credentials in the node: Bulk Dropcontact Requests. +++++++++++++++++++++++++++++++++++++++++ Step4: Connect your output source by mapping the data you like to use. +++++++++++++++++++++++++++++++++++++++++ Step5: Node: "Slack" (OPTIONAL) Connect your slack account, if an error occur, you will be notified. TIP: Try to run the workflow with a batch of 10 (not 250) as it might need to run initially before you will be able to map the data to your final destination. Once the data fields are properly mapped, adjust back to 250.

Use case Slackbots are super powerful. At n8n, we have been using them to get a lot done.. But it can become hard to manage and maintain many different operations that a workflow can do. This is the base workflow we use for our most powerful internal Slackbots. They handle a lot from running e2e tests for Github branch to deleting a user. By splitting the workflow into many subworkflows, we are able to handle each command seperately, making it easier to debug as well as support new usecases. In this template, you can find eveything to setup your own Slackbot (and I made it simple, there's only one node to configure 😉). After that, you need to build your commands directly. This bot can create a new thread on an alerts channel and respond there. Or reply directly to the user. It responds for help request to return a help page. It automatically handles unknown commands. It also supports flags and environment variables. For example /cloudbot-test info mutasem --full-info -e env=prod would give you the following info, when calling subworkflow. How to setup Add Slack command and point it up to the webhook. For example. Add the following to the Set config node alerts_channel with alerts channel to start threads on instance_url with this instance url to make it easy to debug slack_token with slack bot token to validate request slack_secret_signature with slack secret signature to validate request help_docs_url with help url to help users understand the commands Build other workflows to call and add them to commands in Set Config. Each command must be mapped to a workflow id with an Execute Workflow Trigger node Activate workflow 🚀 How to adjust Add your own commands. Depending on your need, you might need to lock down who can call this.

Convert PostgreSQL table to CSV CSV is a super useful and universal way to transfer data between different tools. This workflow gives an example of how to take data from PostgreSQL and convert it easily into a CSV. What you need Before running the workflow, please make sure you have access to a remote PostgreSQL server and have table data: book_title,book_author,read_date Demons,Fyodor Dostoyevsky,2022-09-08 Ulysses,James Joyce,2022-05-06 Catch-22,Joseph Heller,2023-01-04 The Bell Jar,Sylvia Plath,2023-01-21 Frankenstein,Mary Shelley,2023-02-14 How it works Trigger the workflow on click Declare the name of the Excel file and sheet names Remotely connect to the PostgreSQL database and specify query execution Write the query data to CSV The detailed process is explained further in the tutorial: https://blog.n8n.io/postgres-export-to-csv/

This n8n workflow is designed for security monitoring and incident response when suspicious login events are detected. It can be initiated either manually from within the n8n UI for testing or automatically triggered by a webhook when a new login event occurs. The workflow first extracts relevant data from the incoming webhook payload, including the IP address, user agent, timestamp, URL, and user ID. It then splits into three parallel processing paths. In the first path, it queries GreyNoise's Community API to retrieve information about the investigated IP address. Depending on the classification and trust level received from GreyNoise, the alert is given a High, Medium, or Low priority. This priority is assigned based on the best practices documentation from GreyNoise on how to apply their data to analysis. Once a priority is assigned, a message is sent to a Slack channel to notify users about the alert. The second path involves fetching geolocation data about the IP address using IP-API's Geolocation API and merging it with data from the UserParser node. This data is then combined with the data obtained from GreyNoise. In the third path, the UserParser node queries the Userparser IP address and user agent lookup API to obtain information about the user's IP and user agent. This data is merged with the IP-API data and GreyNoise data. The workflow then checks if the IP address is considered an unknown threat by examining both the noise and riot fields from GreyNoise. If it is considered an unknown threat, the workflow proceeds to retrieve the last 10 login records for the same user from a Postgres database. If there are any discrepancies in the login information, indicating a new location or device/browser, the user is informed via email. Potential issues when setting up this workflow include ensuring that credentials are correctly entered for GreyNoise and UserParser nodes, and addressing any discrepancies in the data sources that could lead to false positives or negatives in threat detection. Additionally, the usage of hardcoded API keys should be replaced with credentials for security and flexibility. Thorough testing and validation with sample data are crucial to ensure the workflow performs as expected and aligns with security incident response procedures.

Sync your Google Sheets Data with your Postgres database table, requiring minimal adjustments. Follow these steps: Retrieve Data: Pull data from Google Sheets and PostgreSQL. Compare Datasets: Identify differences, focusing on new or updated entries. Update PostgreSQL: Apply changes to ensure both platforms mirror each other. Automate this process to regularly synchronize data. Before starting, grant necessary access to both Google Sheets and PostgreSQL, and specify the data details for synchronization. This streamlined workflow enhances data consistency across platforms. This example is a one-way synchronization from Google Sheets into your Postgres. With small adjustments, you can make it the other way around, or 2-way.

Do you consistently forget to set a Default Error Workflow when creating new workflows? Then this helper workflow is for you! When activated, this helper workflow will: Scan ALL other workflows every 4 hours Make sure ALL workflows have a default error workflow set (based on what Workflow ID you provide) This helper will SKIP OVER any workflows that have the default_error:false tag set (make sure your default error workflow has the default_error:false tag set, so that you don't end up with recursive loops during errors) Setup Nodes: Once imported, edit the Set Vars node with your default_error_workflow_id value. If you want to change the default_error:false tag to some other tag name, you can do so here as well. You need to update the Set Default Error Workflow node with your PostgreSQL credentials to access the n8n database.