n8n node categories

SEO work moves through several steps: research a topic, plan a page, review and publish content, then check how it performs in search. This category brings SEO-focused n8n community nodes together for people who want to connect that work in workflows. Use the category to explore SEO nodes for n8n and find actions that fit a specific job. The available actions vary. Check each listing for the operations, fields, credentials, and setup requirements before building a workflow around it. What SEO nodes can help you do SEO workflows often support work in a few areas: Keyword research and planning: collect ideas, review terms, group topics, and move approved keywords into a content plan. Content operations: organize briefs and articles, manage updates, and connect drafting, review, and publishing steps where supported. Search performance: bring page or query results into reports, compare time periods, and flag changes for review. Page checks: inspect URLs, index status, or overlap between pages when those actions are available. A node handles the actions it exposes. Other n8n steps can move the returned data to a review, report, or follow-up task. Keyword research and content planning Keyword research starts with a topic, product, or question people search for. An SEO workflow can collect related terms and keep them together with the page or content plan they belong to. Where the available actions return search metrics, you can use those fields to sort or review the ideas. A person still needs to decide whether a keyword fits the site's audience and purpose. Check for the page's intent, existing coverage, and overlap with other content before assigning it. Once a topic is approved, n8n can carry it into the next planning step so the research does not sit in a separate export. Content production and page updates A content workflow can follow an article from topic to published page. Depending on the actions available, an SEO node may create an outline or draft, retrieve article details, update existing content, or return a publishing status. n8n can connect those actions to review and approval steps. For example, a draft can go to an editor before publishing, while a page update can keep its target URL and review notes with it. Publishing and updating require the right action and account connection, so check those requirements first. Keep a person in the loop when a page contains product details, pricing, or technical claims. Generated content can provide a starting draft, but a reviewer should confirm that it is accurate and useful before it goes live. Search performance and page checks After a page is published, performance data can help decide what to review next. If an available action returns it, a workflow can collect impressions, clicks, click-through rate, page or query results, and keyword positions. You can group the information by date or page, send it to a report, and flag changes for a closer look. Some SEO actions work at the URL level. They may check whether a page is indexed or crawled, or help identify queries that overlap across pages. These capabilities depend on the node and the connected account. A change in search performance gives you a reason to investigate; it does not explain the cause on its own. Build a workflow around one SEO task Start with a task that repeats and has a clear next step. For example: Collect keyword ideas and route approved topics into a planning queue. Gather page performance on a schedule and send the results for review. Check a URL and create a follow-up when the result needs attention. Keep the first workflow focused. Choose the input, decide what result you need, and identify who or what should receive it. Run a small set first and review the returned data. This helps catch missing fields, duplicate records, or unexpected output before you add more steps. Choose an SEO node that fits Start with the task you want to handle, then compare the available actions. Check whether a node works with the records you have, such as keywords, articles, sites, or URLs. Confirm what data it returns and whether it can read, create, update, or publish the information you need. Before installing, review: Required credentials and account permissions Supported actions and returned fields Any documented limits or prerequisites Compatibility with your n8n setup Community node requirements can vary. Use the individual listing for current installation details. Provenance and verification readiness SEO nodes listed in this category are prepared for n8n verification, and their published releases carry npm provenance. Provenance is a signed record that links a release to its source and build, so you can trace how that release was produced. Provenance and n8n verification are separate. Provenance helps trace a release; it does not mean n8n has verified the node. n8n makes the final verification decision, so check the current status shown on each listing. Create an n8n node for your SEO tool Build an SEO product? NativeShip helps you create and publish an n8n community node so your users can connect your product to their workflows. Try NativeShip .

AI & LLM nodes connect n8n workflows with AI products, language-model services, and the systems that support them. Some integrations handle requests to a model. Others connect services for document ingestion, persistent memory, user context, or search. This category helps n8n users find a community node for the step they need. Each listing has its own operations, credentials, and platform requirements, so check those details before building around it. AI workflows often need more than a prompt and a response. They may need to collect source material, make relevant context available, store useful information for a later run, or keep records organized by person or project. The AI & LLM category includes nodes for those supporting services as well as AI APIs. The current category listing focuses on storing and searching documents and memories, retrieving profile context, and managing related data. What AI & LLM nodes can do in n8n Store documents and conversation context A workflow can send supported text, URLs, files, or conversation data to a connected service for processing. This gives later workflow runs a place to look for information from earlier interactions or approved reference material. The exact accepted inputs and processing steps depend on the node and the service behind it. For example, a workflow could save a conversation summary after a support interaction, or add a reviewed document to a searchable knowledge collection. A node that supports batch operations can also help move several records in one run. Check the listing for supported formats, size limits, and whether processing finishes immediately or continues in the background. Find relevant information before a model step A memory or document search can return context related to a question, topic, or record. Some services support semantic search, keyword matching, or filters that narrow results by metadata or a defined scope. An n8n workflow can pass those results into a separate model step, then route the response for review or delivery. Search is useful when a model needs information from previous conversations or from a collection of reference documents. It does not make the returned information automatically correct or complete. Review the result fields and test queries against the material you expect the service to find. Retrieve user or project context Some AI services keep profile information alongside documents and memories. A workflow can retrieve that context before handling a request, then save a verified update when an interaction adds something useful. This can support personalized assistance or project-aware responses when the service and node expose those operations. Keep each record associated with a clear user, workspace, or project scope. A consistent tag or container can help separate records during search. Confirm how the connected service applies those scopes, and do not treat a label as an access-control boundary unless its documentation says it is one. Maintain the information behind an AI workflow AI-related services may expose actions for reviewing document status, updating records, removing outdated information, or syncing supported external sources. These maintenance steps help keep a knowledge collection useful as the source material changes. The available actions differ by node, and supported external sources are package-specific. Examples of AI workflows with n8n The category nodes can sit between the event that starts a workflow and the next step that uses the result. For example: Prepare a knowledge collection: receive approved content, add it to a connected service, and check its processing status before making it available for search. Answer with relevant context: take an incoming question, search records within the right user or project scope, pass the returned context to a model step, then route the answer through the appropriate review or delivery step. Keep useful conversation history: after an interaction, save a concise summary so a later run can retrieve relevant details without relying on the previous execution still being active. Refresh stored information: update or remove a record when its source changes, or run a supported sync and route failures for follow-up. These patterns use other n8n steps around the community node. A category node only performs the actions shown in its listing; it does not automatically provide the trigger, model call, approval, or delivery step around it. Choose an AI & LLM node that fits the job Start by naming the part of the workflow you want the node to handle. A direct model request, a memory lookup, document storage, profile retrieval, and source synchronization are different jobs. Look for a listing that exposes the operation you need and returns fields your next workflow step can use. Before installing, check: Supported operations: Can it add, search, retrieve, update, or delete the records your workflow uses? Inputs and outputs: Which content types, filters, identifiers, and response fields does it accept or return? Authentication: Does it require an API key, OAuth connection, or another credential, and which permissions does that credential need? Data scope: Can you separate records by user, workspace, project, or another identifier? Processing behavior: Does an action return its result immediately, or should the workflow check a processing status later? n8n compatibility: Review the current installation requirements and verification status on the individual listing. Community node requirements vary. Test with a small, non-sensitive example first. Inspect the returned data and error behavior before connecting the node to a workflow that handles live conversations or important records. Keep credentials in n8n's credential settings, and check what data the service stores before sending it information about users or customers. Provenance and verification The current AI & LLM listing is published with npm provenance. Provenance records a link between a package release, its source, and the build that produced it, so you can inspect how that release was created. Provenance and n8n verification are separate. A provenance record does not mean n8n has verified a node. Check the listing for its current verification and installation status; the current listing is marked for self-hosted n8n. Build an n8n node for your AI product If you build an AI or LLM SaaS and want n8n users to connect it to their workflows, NativeShip can help you create and publish a community node for your product. Try NativeShip .

Analytics & BI nodes connect n8n with services that collect, organize, or report metrics. Depending on the integration, those metrics may describe product usage, website activity, revenue, customer behavior, or wider business performance. This category helps n8n users find community nodes that bring data from analytics and business-intelligence tools into workflows. Once metrics are available in n8n, you can route them into a report, compare them with a threshold, combine them with other workflow data, or send a follow-up to the person who needs to review them. Each node exposes its own actions and fields, so check the listing to see exactly which service data it can retrieve and how it returns that data. What Analytics & BI nodes can help you work with Product analytics Product analytics can show how people use an application: which events they trigger, where they move through a funnel, which features they return to, and where they stop. When a connected service exposes these events or reports through its API, an n8n node can bring selected results into a workflow for a scheduled digest, an internal alert, or a review queue. The event names and definitions come from the product and its tracking setup. Before using a metric, confirm what it counts, which users or sessions it includes, and what date range the result covers. An event total without that context can be easy to misread. Web analytics Web analytics data can include visitors, sessions, traffic sources, landing pages, and conversion events. A workflow can gather a chosen set of metrics on a schedule and pass them into a report or another system. You can also use a workflow to flag a value that needs attention, provided the source node returns the fields and time ranges needed for that check. Web analytics definitions vary. For example, a visitor count and a session count describe different things, and attribution can depend on the connected service's reporting rules. Check those definitions before comparing results across sources. Reporting and business intelligence Reporting and BI integrations can expose saved reports, datasets, query results, or business measures. In n8n, those results can become part of a larger process: distribute a weekly summary, route an unusual result for review, or pass selected figures to a planning workflow. Some nodes only read data; others may support additional actions. Do not assume a node can create or edit dashboards just because it belongs to an analytics category. Review its listed operations and the permissions its credentials require. Revenue and business metrics Some analytics-related services expose revenue, growth, customer, or marketplace data rather than website or in-product events. The current Analytics & BI listing includes operations for browsing structured records with revenue and growth fields, applying filters, and retrieving a detailed profile. This can help workflows use business metrics as inputs alongside other information. Examples of analytics workflows in n8n A category node can retrieve the data while other n8n steps schedule the run, transform results, and deliver the next action. Common patterns include: Send a metrics digest: retrieve selected product or web metrics on a schedule, format the relevant fields, and send a concise report to the people who use it. Flag a change for review: check a returned value against a threshold and route the result for follow-up. For a week-over-week or month-over-month comparison, the workflow needs a date-range option from the source or a saved earlier snapshot. Bring several measures together: retrieve fields from more than one source, align them by date, product, or another shared key, then send the combined result to a reporting step. Enrich a business record: retrieve a metric-rich profile or record, then add selected fields to a downstream process when the node supports the required filters and lookup. These patterns depend on the operations available in each listing. A node that returns current totals may not provide historical data, and a workflow cannot calculate a trend unless it receives comparable time periods or stores earlier results. Choose a node by the metric you need Start with the question you want the workflow to answer. Then check whether a node can retrieve the relevant metric, report, or record. Compare the returned fields with the next step in your workflow so you know whether the data can be grouped or compared in the way you need. Before installing, review: Metric definitions: What does each number count, and which events, users, or records are included? Time period: Can you choose a date range or reporting interval? Does the response include a timestamp or timezone? Filters and pagination: Can you narrow a report to the relevant product, segment, page, or record? Does the node return one page or multiple pages of results? Output fields: Are currency, units, dimensions, and identifiers clear enough for later workflow steps? Credentials and access: Which API key or account permissions are required, and what data can that connection read? Available actions: Does the node retrieve data only, or can it also create or update reports or records? n8n compatibility: Check the listing for current verification and installation requirements. Community node support varies. For comparisons, use the same metric definition and date boundaries on each side. If one source reports calendar months and another returns rolling 30-day totals, keep that difference visible in the report instead of treating the numbers as directly equivalent. Provenance and verification The current Analytics & BI listing is published with npm provenance. Provenance links a package release to its source and build, which helps you inspect how that release was produced. It is separate from n8n verification: provenance does not mean n8n has verified the node. Check the listing for its current verification and installation status. The current listing is marked for self-hosted n8n. Build an n8n node for your analytics product If you build a product analytics, web analytics, reporting, or BI service, NativeShip can help you create and publish an n8n community node so users can bring your data into their workflows. Try NativeShip .

CRM nodes connect n8n workflows to customer relationship management systems, so information from other parts of your business can become a contact, company, deal, activity, or follow-up task. Use this category to find n8n CRM nodes for creating and updating CRM records, finding existing ones, and keeping sales information in sync with the events that matter. Available CRM nodes Attio n8n node ( @nativeship/n8n-nodes-attio ): search, create, update, upsert, and merge Attio records, manage lists, and work with tasks, notes, meetings, and activities. Connects with an Attio OAuth2 credential. Close n8n node ( @nativeship/n8n-nodes-close ): manage Close leads, contacts, opportunities, tasks, sales activities, and reports, including merging two leads. Connects with a Close API key or OAuth2. Looking for prospecting, enrichment, or outreach instead of CRM records? See Sales & Lead Generation nodes , or browse all n8n node categories . The current CRM listings cover common record actions such as creating, finding, and updating people, organizations, and deal records. Depending on the integration, a CRM node may also support upserting or merging records, managing lists, adding notes and activities, or working with opportunities and pipeline reports. For example, the Attio node can upsert and merge records, and the Close node can merge leads and create or update opportunities. Each CRM has its own data model and operations, so check the individual listing before you decide how the workflow should map its data. What CRM nodes can help you do in n8n Create or update contacts and companies When a workflow receives customer or prospect details, a CRM node can create a new contact or organization record, or update an existing one with the latest information. The source could be a signup, an approved lead, a service interaction, or another business event. n8n can normalize the incoming fields before passing them to the CRM. Use a stable identifier, such as an existing record ID or a well-defined matching field, to avoid creating duplicate contacts. If a node offers an upsert action, check which fields it uses to decide whether to update a record or create a new one. A match based on the wrong field can join unrelated people or companies. Keep people, companies, and deals connected CRM records are useful when their relationships are preserved. A contact may belong to a company, while a deal or opportunity may be linked to both a company and one or more people. A workflow can create or find the related records first, then pass their IDs into the next CRM action. CRM systems do not all use the same structure. One may represent a company as a lead or account with contacts nested under it; another may store people, companies, and deals as separate objects. A deal may also be called an opportunity. Close, for example, creates contacts and opportunities on a lead, while Attio works with records of different objects, such as companies and people. Check the node's resource names and required relationship fields before mapping data between systems. Update pipeline stages and sales details Once a deal exists, a workflow may update its stage, owner, value, close date, or custom fields when those actions are available. That can keep a pipeline current after a form submission, a handoff, or a change in another connected system. Before updating a deal, look up the record and confirm that the incoming event refers to the correct one. Preserve the CRM's identifiers and use its available status values. A workflow should not guess a pipeline stage from incomplete data. Add notes, activities, and follow-up tasks CRM integrations may also expose related work such as tasks, notes, meetings, calls, emails, or custom activities. These records give a team context for why a contact or deal changed and what should happen next. For example, after a qualified lead enters a pipeline, n8n can add a note with the source information and create a follow-up task for an assigned owner. The exact activity types and fields depend on the CRM and the node. Examples of CRM workflows in n8n In an n8n CRM integration, the CRM node usually handles the record action while other n8n steps supply the event, prepare the data, and decide what happens next. Common patterns include: Create a contact from an approved signup: map the submitted fields, search for an existing contact, then create or update the CRM record and link it to the right company. Keep company records current: use a source update to find a company by a stable ID or domain, update selected fields, and leave unrelated CRM fields untouched. Open or update a deal: find the related company and contact, then create a deal or update its stage and value when the incoming data meets your rules. Record a customer interaction: add an activity or note to the correct contact or company and create a follow-up task for the next owner. Sync selected CRM changes elsewhere: find the matching record in another workflow destination, map the required fields, and preserve the CRM record ID for later updates. Run the first workflow with a small set of records. Inspect how the node handles missing fields, duplicate matches, custom attributes, and linked records before allowing it to update a larger part of the CRM. Choose a CRM node that fits your data model Start with the record you need to create or update. Then confirm that a node supports the relevant object, its required fields, and the relationships your workflow needs to preserve. Before installing, check: Supported objects: Can it work with contacts or people, companies or accounts, and deals or opportunities? Available actions: Does it create, find, update, upsert, merge, or delete the records you need? Matching behavior: Which fields identify an existing record, and can the workflow keep its CRM ID for later changes? Relationships: Can you associate contacts with companies and deals with the correct people or organization? Custom fields: Does the node expose the fields your workspace uses, and what format do those fields expect? Authentication and permissions: Does it use OAuth or an API key, and does the connected account have permission to read and write the required records? Installation requirements: Review the listing for current verification and n8n compatibility details. The current CRM listings use OAuth or API-key credentials depending on the integration: the Attio node uses an Attio OAuth2 credential, and the Close node accepts a Close API key or OAuth2. Give each credential only the access needed for the workflow, and test a read or lookup action before enabling record changes. Install a CRM node in n8n Both current CRM listings install from npm on self-hosted n8n: In n8n, open Settings → Community Nodes and select Install . Paste the package name from the listing, such as @nativeship/n8n-nodes-attio or @nativeship/n8n-nodes-close . Add the node's credential, then run a read or lookup action first. Only Owner and Admin users can install community nodes from npm. See n8n's community node installation docs for the GUI, manual, and environment-variable methods. If a node disappears after a restart or upgrade, see n8n community node not showing . Provenance and verification The current CRM listings are published with npm provenance. Provenance links a package release to its source and build, helping you inspect how it was produced. Read more in how to publish an n8n node to npm with provenance . Provenance is separate from n8n verification; it does not mean n8n has verified a node. Both current listings are marked for self-hosted n8n, so check each listing for its current verification and installation status. To see what verification involves, read how to get your n8n community node verified . Build an n8n node for your CRM If you build a CRM or customer-data service, your customers will ask whether you have an n8n integration. NativeShip turns your OpenAPI spec into an official, branded n8n community node, published under your own GitHub and npm accounts, and the same project covers Make, Zapier, and Activepieces. Unsure whether it's worth it? Read should your SaaS build an n8n integration? Wondering what can be generated from your spec? See generate an n8n node from an OpenAPI spec . Ready to start? Plans begin at $149 one-time. See pricing or try NativeShip .

Sales & Lead Generation nodes connect n8n to services used to find prospects, enrich lead records, manage outreach, and keep pipeline information current. They help move data from a sales or prospecting service into the next workflow step, where you can review a lead, assign follow-up, update a status, or prepare a report. The available operations vary by node. The current category listing includes actions for searching and extracting leads, retrieving profile and company details, managing campaign and lead records, reading conversations, and sending supported messages. Check each listing to see which actions it exposes and what information it returns before you build a workflow around it. What Sales & Lead Generation nodes can help you do Find and qualify prospects Prospecting starts with a clear description of the people or companies you want to reach. A connected service may let you search by professional, company, industry, technology, location, or other profile criteria. Some nodes can also collect lead records from a supported search or extraction process and return them to n8n when the job finishes. A workflow can pass those results through a review step before adding them to a pipeline or campaign. This gives a salesperson a chance to check that the records fit the audience and that the source returned enough detail to support a useful next step. Enrich lead records Lead enrichment adds useful context to a basic record, such as a current role, seniority, company details, or available contact information. When the connected service exposes those fields, n8n can carry them into a later qualification or outreach step. Check which fields are returned and where they came from. A missing value is different from a verified value, and not every lead source provides the same coverage. Keep the original record identifier so an enriched result can be matched back to the right person or company. Manage outreach and conversations Some sales services let workflows work with outreach campaigns, leads, sender accounts, and inbox conversations. Depending on the node, you may be able to add leads to an existing campaign, check campaign status, pause or resume activity, read a conversation, send a supported message, or record a lead's progress. Campaign creation and sequence editing are separate capabilities. A node that can read or pause a campaign may not let you build its steps or change its targeting. Review the listed operations before assuming the full outreach sequence can be configured from n8n. Keep pipeline information moving Lead generation does not end when a prospect is found. A workflow can update lead status after a reply, route a conversation to the right person, or pass selected fields to another system. If a connected service returns campaign or inbox activity, n8n can also use those results to prepare a follow-up queue or activity summary. The exact handoff depends on the nodes and services in your workflow. Check whether an action updates the original record or only returns data, and decide how the workflow should handle duplicate leads, missing fields, or an incomplete search job. Examples of sales workflows in n8n A Sales & Lead Generation node can handle one part of a larger process while other n8n steps start the workflow and route its results. For example: Review a new prospect list: start a supported search, check when it is complete, retrieve the results, and send them for review before adding selected leads to a campaign. Enrich leads before outreach: retrieve profile or company details, keep the source identifiers with each record, and pass qualified leads to an existing campaign when the node supports that action. Route replies for follow-up: retrieve supported inbox conversations, match them to a lead or campaign, and update the lead's status or create a task for a salesperson. Monitor campaign activity: retrieve campaign details and lead progress on a schedule, then share a summary or route records that need attention. For actions that run asynchronously, check the job status before trying to use its results. For messages and connection requests, confirm the connected account, recipient, and message data before sending. A small test run can reveal missing fields or unexpected records before a workflow handles a larger list. Choose a sales node that fits your workflow Start with the part of the sales process you want n8n to handle: prospect search, data enrichment, campaign management, inbox activity, or pipeline updates. Then compare the available operations with the next step you plan to take. Before installing, review: Lead source and filters: Which people or companies can it find, and which search fields can you use? Returned data: Does it provide the profile, company, contact, campaign, or conversation fields you need? Record matching: Does the response include stable IDs or profile URLs so you can avoid duplicate records? Action scope: Can it read data, add leads, update statuses, manage campaigns, or send messages? Which sequence settings are available? Job behavior: Does prospect search or extraction finish immediately, or do you need to check its status and retrieve results later? Credentials and account access: Which API key or connected sender accounts are required, and what permissions do they have? Installation requirements: Check the individual listing for current verification and n8n compatibility details. Keep a review step where a person needs to approve lead fit, message content, or an unusual result. Also check the source service's sending limits and terms before automating outreach at scale. Provenance and verification The current Sales & Lead Generation listing is published with npm provenance. Provenance links a package release to its source and build, helping you inspect how the release was produced. It is separate from n8n verification: provenance does not mean n8n has verified the node. Check the listing for its current verification and installation status. The current listing is marked for self-hosted n8n. Build an n8n node for your sales product If you build a prospecting, enrichment, or sales-engagement SaaS and want n8n users to connect it to their workflows, NativeShip can help you create and publish a community node for your product. Try NativeShip .

Email & Newsletters nodes connect n8n workflows with services for sending email, managing subscriber lists, validating addresses, and working with inbox activity. They can help move email data from a form, list, or inbox into another workflow step. Each community node supports different actions, so check its listing before relying on it to send, subscribe, unsubscribe, or read messages. The current category listing focuses on checking individual email addresses and submitting lists for bulk verification. It returns verification results and supports checking the status of a bulk task. This can help prepare address data for a later email or newsletter step. The current listing does not send campaigns, manage subscriber preferences, or read inbox messages; look for those specific actions in a node listing before planning around them. What email and newsletter nodes can help you do Check an address before using it An email verification step can inspect an address before a workflow saves it to a contact record or includes it in a later list update. Depending on the service and verification mode, results may cover syntax, domain mail records, disposable addresses, role accounts, or deeper mailbox signals. Verification modes can differ in speed and depth. A quick check may confirm basic address and domain signals without checking whether an individual inbox exists. A deeper check can take longer and may return more detail. Review the operation description and output fields so the workflow responds appropriately to each status. An address check is a useful signal, not a promise that a future message will be delivered or land in the inbox. Mailboxes and server behavior can change after a check, and some domains accept mail for addresses that do not belong to a specific person. Process a newsletter list When a node supports bulk verification, n8n can submit a list and retrieve the results after processing finishes. The current listing supports bulk tasks of up to 50,000 addresses. It returns a task identifier, then provides actions to check progress and retrieve completed results. That asynchronous pattern works well for list cleanup: start the task, check its status, and route the returned addresses according to their result. Keep uncertain or unknown results in a review path instead of treating every response as a simple yes or no. Preserve any record IDs and original contact fields so the results can be matched back to the right subscribers. Address validation and newsletter-list management are separate jobs. A verifier can report on address signals, but it does not establish consent, update a subscriber's preferences, or unsubscribe someone. Keep subscription status and consent information attached to the contact record when a workflow passes data to an email service. Send email and manage subscriber changes Other nodes in this category may expose actions for sending transactional messages, managing newsletter subscribers, or updating list membership. When those actions are available, n8n can connect a signup or business event to an email step, or route an unsubscribe request to the service that owns the list. Check whether a node sends a one-off message, starts a campaign, edits a subscriber, or changes list membership. These are different operations with different inputs. The current category listing does not provide these send or subscription-management actions, so confirm that a suitable node is listed before planning the workflow. Bring inbox activity into a workflow An inbox integration can expose incoming messages, conversation details, or reply status for routing and follow-up. A workflow might send a message to a review queue, attach it to a customer record, or alert the person responsible for the conversation when the connected node supports those actions. Inbox access also varies by service. Check whether a node reads a shared inbox, an individual mailbox, or only message history from its own campaigns. The current category listing handles address verification rather than inbox messages. Examples of email workflows in n8n The category nodes can handle one step in a wider n8n process. For example: Check a new signup address: validate an address before the workflow saves it, then route the result based on the fields returned by the verification service. Review a large contact list: submit a bulk verification task, check its progress, retrieve the results, and match them back to the original records. Prepare a newsletter update: confirm the contact is subscribed and eligible for the planned update, then pass the address to a list-management action when a suitable node is available. Route an incoming reply: use an inbox node, when listed, to send the conversation to the right person or customer record for follow-up. For bulk checks, wait for the task to finish before using its results. For sending or list changes, confirm the recipient, list, and intended action before the workflow runs. Test with a small set first and inspect how the service represents valid, invalid, disposable, catch-all, and unknown results. Choose an email node that fits the task Start with the job you want n8n to handle: verify one address, process a list, send a message, change subscriber status, or route inbox activity. Then compare that job with the node's available operations and the service that owns the data. Before installing, check: Action type: Does the node verify addresses, send messages, manage subscribers, or read inbox data? Input and output: Which fields does it require and return? Can you match the result to an existing contact? Verification depth: Does the selected mode check basic domain signals or deeper mailbox status? Bulk behavior: Is processing immediate or asynchronous? Does the node provide task status and result retrieval? List state: Can the action read or change subscription status and preferences, or does it only verify the address? Credentials and limits: Which API key or account permissions are needed? Check operation-specific fields, credits, and service limits. Installation: Review the listing for current verification and n8n compatibility details. Keep contact consent and subscription preferences in the system that manages the list. An address result can help you decide how to process a record, but it cannot tell you whether the person agreed to receive a newsletter. Provenance and verification The current Email & Newsletters listing is published with npm provenance. Provenance links a package release to its source and build, helping you inspect how the release was produced. It is separate from n8n verification: provenance does not mean n8n has verified the node. Check the listing for its current verification and installation status. The current listing is marked for self-hosted n8n. Build an n8n node for your email product If you build an email, newsletter, or inbox SaaS and want n8n users to connect it to their workflows, NativeShip can help you create and publish a community node for your product. Try NativeShip .

Social Media nodes connect n8n workflows with social networks and creator platforms. Depending on the integration, they can publish or schedule content, retrieve post details, read available activity, or collect performance metrics. This category helps n8n users find community nodes for moving social data into and out of a workflow. The available actions vary by node. The current category listing supports creating drafts, publishing or scheduling posts across connected accounts, checking publication results, and retrieving post analytics. Its read actions focus on posts and their results; they do not currently provide a general feed, comment, or mention-monitoring stream. Check each listing to confirm which accounts, content types, and read operations it supports. What Social Media nodes can help you do Prepare and publish content A publishing node can take a caption and optional media from an earlier workflow step, then send the post to one or more connected accounts. Depending on the service, it may also support scheduled publishing or saving a draft for review. Some services let you adjust captions or settings for each platform so the same source content can be prepared for different formats. Check which content types are supported before building a workflow around a post. A platform may require an image or video, have limits for captions, or treat drafts differently from scheduled posts. The node listing should make clear whether an action publishes immediately, schedules a time, or saves a draft. Confirm what happened after publishing Post results can tell a workflow whether a target post was published and provide the resulting status or live URL. This helps route successful posts for reporting and send failed or incomplete results to a review step. When publishing to several accounts, inspect results per destination so one success does not hide a failure on another. Read post analytics Some social publishing services expose post performance such as views, likes, comments, or daily engagement changes. A workflow can refresh the available analytics, retrieve results, and prepare a summary for a content review or reporting process. The current category listing includes actions for syncing analytics and retrieving post-level or daily metrics. These results describe activity for posts available through the connected service. They are not the same as a full social listening feed, audience report, or stream of every comment and mention across a network. Read activity and monitor creator channels Other social and creator-platform nodes may let workflows read posts, comments, messages, mentions, or channel data. Those actions can support a monitoring workflow that routes a new item for review or records activity alongside other business information. Read access depends on the connected service, account permissions, and the operations exposed by each node. The current category listing focuses on publishing and analytics, so check for a specific feed, comment, inbox, or mention operation before expecting to monitor that activity from n8n. Examples of social media workflows in n8n A Social Media node can handle publishing or data retrieval while other n8n steps prepare content and route the result. For example: Prepare a post for review: collect approved copy and media, save a draft through a supported action, and send the draft details to a reviewer before scheduling. Schedule across connected accounts: select the intended accounts, set the publishing time, and check each returned result for its status and live URL. Report on recent posts: refresh available analytics, retrieve the metrics, and send a short summary to the people who review content performance. Route social activity: when a listed node can read a comment, message, or mention, send the returned item to a review queue or the person responsible for responding. These patterns depend on the actions available in a particular listing. A publishing node does not automatically read every network feed, and a metrics action may require a separate sync before it returns recent data. Choose a Social Media node that fits Start with the job you want to do: publish a post, schedule a draft, retrieve a result, read activity, or collect analytics. Then compare the node's operations with the connected accounts and the next workflow step. Before installing, review: Supported accounts and platforms: Which connected account types can the node use? Content formats: Does it support the text, media, and platform-specific settings your post requires? Publishing behavior: Can it publish now, schedule, save drafts, or update and delete scheduled content? Read access: Does it retrieve post results and metrics, or can it also read feeds, comments, inbox messages, and mentions? Analytics detail: Which metrics and time ranges are returned, and do you need to sync data first? Credentials and permissions: Which API credential or account authorization is required? Installation requirements: Check the listing for current verification and n8n compatibility information. Test with one account and a draft or low-risk post first. Review how the node handles media, platform-specific errors, and partial results before scheduling a workflow across multiple accounts. Provenance and verification The current Social Media listing is published with npm provenance. Provenance links a package release to its source and build, helping you inspect how the release was produced. It is separate from n8n verification: provenance does not mean n8n has verified the node. Check the listing for its current verification and installation status. The current listing is marked for self-hosted n8n. Build an n8n node for your social product If you build a social publishing, analytics, or creator-platform service and want n8n users to connect it to their workflows, NativeShip can help you create and publish a community node for your product. Try NativeShip .

Customer Support nodes connect n8n workflows with help desks, ticketing systems, live chat, and customer-support platforms. They can create or update tickets, retrieve conversations, pass a question to a support agent, or move customer context to the next step in a workflow. Each community node supports its own channels and operations, so check the listing before planning a process around a particular action. The current category listing covers support agents, conversations, helpdesk tickets, knowledge sources, and approved template messages. It includes actions for creating and updating tickets, checking their status and assignment, reading conversation history, and working with the content an agent uses to answer questions. The exact coverage depends on the resource and action you select. What Customer Support nodes can help you do Create, route, and update tickets A ticketing node can create a support request from an event in n8n, such as a customer form or an escalation from another workflow. It may let you set the subject, priority, team, or assignee, then update those fields as the request moves through your support process. Ticket actions can also search or list requests and retrieve their message threads. This gives a workflow enough context to route a ticket, prepare an internal summary, or notify the right owner. Use the ticket ID or ticket number returned by the service when you update or reply to a specific request. Some services send replies asynchronously. A successful API response may mean the reply was recorded, while delivery to the customer happens later. Check the action description and any delivery status before treating a recorded message as delivered. Work with live chat and support conversations Conversation actions can send a question to a support agent, retrieve its response, search conversation history, or export messages for review. A workflow can use these actions to prepare an answer, find the right prior interaction, or route an issue for human follow-up. Conversation history may depend on its source. Some actions cover conversations created through an API, while separate export actions may include website chat or connected channels. Check how the node handles pagination and source filters so a workflow does not treat one conversation page as a complete history. Keep an agent's support knowledge current Some support platforms let a workflow add or update the material an agent uses to answer questions. Supported sources may include text, question-and-answer pairs, links, or files. After a source changes, processing or training may continue in the background, so check its status before relying on the updated material in a customer conversation. This can help keep support answers aligned with current product details or policies. A content update alone does not confirm that a source has finished processing; use the available status action when the service provides one. Connect customer messages to the right next step Support nodes may expose messaging templates, team lists, ticket statuses, or assignment options. n8n can use those values to route a request to the correct team, attach a conversation to a ticket, or send a supported message when the workflow has the required information and permissions. Keep a person involved when a request needs judgment, account-specific investigation, or a response that could affect a customer's access or billing. The node handles the action shown in its listing; your workflow defines when to run it and where to send the result. Examples of customer-support workflows in n8n A Customer Support node can manage a ticket or conversation while other n8n steps receive the event and decide what should happen next. For example: Create a ticket from an escalation: collect the issue details, create a ticket with the needed priority, and route it to a team or assignee. Send a conversation for review: retrieve a chat or message thread, attach its context to a follow-up task, and notify the person responsible for responding. Prepare an agent response: pass a customer question to a support agent, then route the response to a review step or return it through the connected channel when appropriate. Refresh support knowledge: add or update an approved source, check its processing status, and flag failures for follow-up. Track ticket progress: look up an existing ticket, update its status or priority, and record the next action for the support team. Before enabling replies or ticket changes, test with a sample request and confirm how the service represents ticket status, message delivery, and source-processing results. Keep the conversation or ticket identifier with the data so later workflow steps update the same record. Choose a Customer Support node that fits Start with the support job you want n8n to handle: create or update a ticket, read a live-chat conversation, send a response, manage agent knowledge, or route a request. Then check that the node supports the channel and record type used by your team. Before installing, review: Ticket actions: Can it create, search, list, update, assign, or reply to tickets? Conversation coverage: Which sources does it read, and can it retrieve the full message history? Response behavior: Is a reply sent immediately, queued, or only recorded for later delivery? Knowledge sources: Which content types can it add or update, and how do you know processing is complete? Routing fields: Can it set the team, assignee, priority, and status values configured in your support workspace? Credentials and access: Which API key or account permissions does it require? Installation requirements: Check the listing for current verification and n8n compatibility details. Provenance and verification The current Customer Support listing is published with npm provenance. Provenance links a package release to its source and build, helping you inspect how the release was produced. It is separate from n8n verification: provenance does not mean n8n has verified the node. The current listing is marked for self-hosted n8n, so check its verification and installation status before installing. Build an n8n node for your support platform If you build a helpdesk, live-chat, or customer-support platform and want n8n users to connect it to their workflows, NativeShip can help you create and publish a community node for your product. Try NativeShip .

Payments & Finance nodes connect n8n workflows with payment providers, banking services, crypto platforms, and financial-data systems. They can help move financial information between services, retrieve account or transaction records, and pass those details into the next step of a workflow. What a node can do depends on the service and the operations shown in its listing. The current category listing focuses on retrieving records from a creator account: one-time supporters, membership details and status, and extra purchases. Its available operations are read-only. They can fetch an individual record or list records in pages, but they do not create a payment, issue a refund, transfer funds, or change a membership. If you are looking for a specific money movement or account action, check the listing before designing a workflow around it. What Payments & Finance nodes can help you do Retrieve payment-related records Financial workflows often need a reliable view of what has already happened. A node that reads records can fetch an individual supporter, member, or purchase, or return a paginated list for review and processing. This is useful when a workflow needs to look up account activity, prepare a report, or pass financial context to another step. The current listing can retrieve one-time support records and any associated messages the service provides. It can also retrieve membership information, including whether a membership is active or inactive, and details about extra purchases. These are account records, not instructions to charge someone or alter their account. Check membership and supporter status Membership data can help answer practical questions: whether a person has an active subscription, whether their status has changed, or which supporters are associated with an account. A workflow can use the returned status to prepare a report, route a record for review, or update a separate system when that system and its permissions allow it. Treat the status returned by the connected service as the source for that record. If a workflow uses the result to grant access, change a customer record, or send a message, decide how often to refresh the data and what should happen when a record is missing or its status is unclear. A read operation does not itself make that decision or change the source account. Review purchases and supporter activity Purchase and supporter records can support routine reporting and account review. For example, a scheduled workflow could retrieve another page of records, compare them with data from an earlier run, and prepare a summary for a team. Supporter messages, when returned by the service, can provide context for a person reviewing the activity. Pagination matters when a service returns large lists. A workflow should follow the node's pagination options and account for records that appear after an earlier run. Avoid treating the first page as a complete history unless the listing says it returns all matching results. Keep a stable identifier and relevant timestamps where available so downstream steps can distinguish new records from records already processed. Plan financial workflows around the available actions The phrase “Payments & Finance” covers several kinds of integrations, but category membership does not mean every listing can perform every financial operation. A payment-related node might expose reporting or lookup actions, while a different service integration might support account data or other operations. Verify the resource, action, filters, and limits in the individual listing before relying on a capability. For the listing currently available here, plan around retrieving records. If your workflow needs to react to an event, confirm that the event comes from a separate trigger or workflow step; the current listing provides retrieval actions rather than a payment-event trigger. If a process needs to charge, refund, transfer, or update a financial record, use an integration that explicitly supports that operation and confirm the service account has the required permissions. Reconcile records across workflow runs Repeatedly retrieving a list can return records that a workflow has already handled. For a scheduled report or sync, retain a stable record identifier and compare it with the identifiers from earlier runs. Where the service provides a creation or update time, use it to narrow the next retrieval, while leaving enough overlap to catch records that arrive late or are updated after their first appearance. Because the current listing returns paginated results, a workflow should account for every page it needs to process. Keep track of the page or cursor as the service documents it, and decide what to do if a run stops partway through. Saving progress only after a page is processed can help prevent a partial run from being mistaken for a complete sync. The exact method depends on the pagination options in the listing and the way the workflow stores its last successful run. Use financial data for reporting and review Retrieved records can support summaries of supporter activity, membership status, and purchases. A workflow might group records by date, separate active from inactive memberships, or prepare a list for a person to review. If the data will be combined with another source, match records using a reliable shared identifier where possible; names and email addresses can change or appear in different formats. Decide what the report means before calculating totals. A purchase record, a payment attempt, a settled transaction, and a refund can represent different stages of financial activity. The current listing returns records from its connected account, but a returned record alone does not establish how the service defines settlement or how an amount should be treated for accounting. Check the source service's field definitions and use a suitable financial system for formal books and reconciliation. Keep the workflow's role clear Read-only access is useful when a workflow needs to observe account data without changing it. It can retrieve records for a report, enrich context for another step, or prepare a review queue. That boundary is also a practical safeguard: the current listing cannot accidentally create a charge or edit the source membership because those actions are not part of its operation set. If a later workflow step changes a record in another system, keep that action separate from the retrieval and make the condition explicit. For example, a membership status returned by this listing can inform a review, but it should not be treated as authorization to make an unrelated account change unless the policy for that change is defined and the receiving system supports it. Clear workflow names and a human review step for uncertain cases make the data's role easier to understand later. Using finance data carefully in n8n Financial information can include personal details, purchase history, account identifiers, and messages. Connect only the account and data the workflow needs. Keep credentials in n8n's credential settings, restrict who can edit or run workflows that use them, and avoid placing access tokens or sensitive account details in logs, notifications, or execution data that does not need them. Check how the connected service represents dates, currency, amounts, status, and missing values before using them in calculations. A numeric amount without its currency can be misleading, and a status field may describe the service's record rather than prove that funds have settled. Use the service's own definitions and test with representative records before sending results to accounting, reporting, or customer-facing steps. The current category listing requires an access token configured as an n8n credential. Its listing includes npm provenance, which provides information about the package's origin; provenance is not the same as verification by n8n. The listing currently indicates that the community node requires self-hosted n8n because n8n Cloud installs only community nodes verified by n8n. Check the listing for the latest installation and compatibility details before you begin. Build a finance node with NativeShip If you build a payment, banking, crypto, or financial-data service and want n8n users to connect it to their workflows, NativeShip can help you create and publish a community node. Try NativeShip .

Files & Documents nodes connect n8n workflows with services that store, process, generate, sign, or extract information from files. They can help move a document through a workflow, prepare it for another step, or return a processed file for review. The exact actions depend on the node and the service it connects to, so check the individual listing before planning around a specific capability. The current category listing focuses on PDF and image processing tasks, along with electronic signature requests. It can start a task, upload source files, process them with a selected option, and download the result. Its signature actions can create a request, list requests, retrieve request details and status, and download signed files. This listing does not provide general-purpose file storage or a template-based document-generation workflow; check the listed operations if you need those functions. What Files & Documents nodes can help you do Process PDFs and images in a workflow A document workflow can begin when a file becomes available to an n8n workflow. The current listing uses a task-based process: start a task, upload one or more source files, run the selected PDF or image operation, then download the processed output. The task and server details returned during setup are used by later steps, so pass those values through the workflow rather than treating each action as an unrelated request. This pattern can fit workflows that need to prepare files before sending them onward. For example, an intake process can pass a PDF or image through a processing step, then route the returned file to another part of the workflow for review or delivery. The available operation and its settings determine what changes to the file; inspect the listing for the current options and required fields. Retrieve the output for the next step After processing finishes, a workflow can download the result and continue with it. If a task produces more than one output file, the current listing returns them together in an archive. Plan for both single-file and multi-file results so a later step does not assume it always receives one standalone PDF. Downloading a result is not the same as keeping a permanent copy. If the workflow needs to retain the original or processed file, include an appropriate storage step and decide how to name or organize the files. Keep a reference to the originating record or task when one is available so a person can trace a processed document back to the request that produced it. Include OCR when the processing option supports it OCR can make scanned pages searchable or provide text that a later workflow step can review. It is useful when a PDF is made from page images and does not already contain selectable text. OCR quality can vary with image clarity, page orientation, language, and layout, so check the output before using extracted text to make a decision or update another system. The current listing accepts a selected PDF or image processing option. Review the available options in the listing to confirm whether OCR is exposed for your setup and what output it returns. Do not assume that every PDF-processing action extracts text, or that OCR will preserve the original layout and formatting. Create and track electronic signature requests Document workflows may need a person to review and sign a file before it moves forward. The current listing can create a signature request from uploaded files and the supplied signer details. It can also list requests, retrieve a request's status, and download the signed files once the signing process is complete. Keep the request information returned by the service available to later workflow steps. A status check can help route a completed request for the next action or leave an unfinished request in a review queue. The listing provides actions for managing requests; it does not itself decide who should sign, when to send a reminder, or what should happen if a request expires or is declined. Connect document steps to the rest of a workflow Files often need to move through several stages: intake, processing, review, signing, and storage. n8n can pass a file or the details of a task from one step to another, then use the resulting document in a later step. Keep the workflow explicit about what happens when processing fails, a signature is still pending, or an expected file is missing. The current category listing provides actions for processing files and managing signature requests. It is not a general file browser, and its listed operations do not create a document from a reusable template. If your workflow needs folder management, template-based generation, or storage, confirm that another connected service or workflow step provides that capability before you design around it. Choose the integration for the document task Start by deciding what should happen to the file. Storage means keeping and organizing a file for later use. Processing means changing or analyzing a file that already exists. Document generation means creating a new file from structured information or a template. E-signatures add a request-and-status process around a document. OCR reads text from scanned pages when that processing option is available. These tasks can connect in one n8n workflow, but they have different inputs and results, and a category listing may cover only some of them. For the current listing, plan around a source file, a processing task, or a signature request. If your workflow must produce a new agreement from customer or order fields, check that the document itself is generated by another step before sending it for processing or signature. This distinction helps avoid selecting a file-processing action when the workflow actually needs a template engine, a file repository, or an OCR result. Account for file and task details Keep the original filename, task identifier, and any related request ID alongside the returned file where possible. This makes it easier to match the result to its source if a workflow handles several documents at once. When a processing task returns an archive, decide whether a later step should keep the archive intact or handle its files individually. Confirm how the workflow responds if a task contains more than one source file or if one file cannot be processed. For signature requests, preserve the request details needed for later status checks and downloads. A workflow that sends a document for signing should have a clear path for the completed result and a separate path for a request that remains pending or needs a person's attention. These details make file handling easier to audit and reduce the chance that a document is lost between processing stages. Plan file workflows with care Documents can contain personal, legal, financial, or confidential information. Limit access to credentials and workflows that handle sensitive files, and review how long execution data and downloaded files are retained. Avoid sending document contents or access tokens to logs, notifications, or other destinations unless the workflow needs them and the destination is appropriate. Check file size, format, password protection, and page count before processing. Test with representative documents, including scans and files with multiple pages, and define how errors should be handled. A successful task response does not guarantee that the output is suitable for every downstream purpose; inspect the result when accuracy, formatting, or signatures matter. The current listing uses an access token configured as an n8n credential and includes npm provenance. Provenance links a package release to its source and build record; it is separate from n8n verification. The listing currently says the community node requires self-hosted n8n because n8n Cloud installs only community nodes verified by n8n. Review the listing for current installation and compatibility details before installing. Build a document node with NativeShip If you build a file-storage, document, e-signature, or OCR service and want n8n users to connect it to their workflows, NativeShip can help you create and publish a community node. Try NativeShip .

Developer Tools & DevOps nodes connect n8n workflows with the services developers use to build, deploy, and maintain software. This category can include source control, CI/CD, cloud infrastructure, monitoring, domain administration, and other developer tooling. A node's capabilities depend on its listed resources and actions, so check what it supports before building a workflow around it. The current category listing focuses on domain and DNS administration. Its available actions cover domain availability, registration and renewal, DNS records, nameservers, contacts, transfers, forwarding, and domain notifications. It is not currently a source-control, build-pipeline, cloud-infrastructure, or monitoring integration. The listing also notes an authentication limitation that users should review before relying on its actions. What Developer Tools & DevOps nodes can help you do Check domain availability and manage domain records Domain operations can help a workflow look up domains associated with an account, check whether a name is available, or retrieve details about a registered domain. The current listing also exposes actions for adding, reading, updating, replacing, and deleting DNS records, as well as changing nameservers and forwarding rules. DNS changes need care. The listed DNS actions apply to domains using the connected provider's authoritative nameservers. If a domain uses nameservers from another DNS provider, its records need to be managed there. A change can affect how a website, email service, or other application is reached, and external resolvers may continue using cached values for a time. Read the current record and confirm the intended change before updating or replacing DNS data. Manage registration, renewal, and transfers The current listing includes actions for registering a domain, renewing it, redeeming a domain in a restoration period, and managing incoming or outgoing transfers. It can also retrieve registration requirements and validate registration details. These actions affect domain ownership, availability, or billing, so they should run only after the domain, contacts, price, and intended outcome have been checked. Some actions can charge the account's payment method. A workflow that runs on a schedule or processes unreviewed input should not submit a registration or manual renewal automatically without a clear approval condition. Use an availability check and any returned price or registration requirements as input to a review step, then run a purchase action only when the request has been confirmed. Update contacts and forwarding settings Domain contact information and forwarding rules can be part of routine administration or a planned migration. A workflow can retrieve existing settings, prepare a proposed update, and route it for approval before making a change. Forwarding rules can redirect visitors from a domain or subdomain to another address, so confirm the source, destination, and redirect behavior before applying one. Contact changes can affect registrant verification and notices about a domain. Keep the account owner involved when an update changes who receives legal, billing, or transfer communications. Use the operation described in the listing and review any confirmation requirements from the domain service. Retrieve and acknowledge domain notifications The current listing includes actions to retrieve domain notifications, inspect notification types, review notification preferences, opt in to notification types, and acknowledge a notification. These actions can help a workflow collect domain-related events and pass them to an internal review or tracking process. The listing exposes notification actions rather than a dedicated event trigger. A scheduled workflow may be needed to check for new notifications, and the workflow should acknowledge an item only after it has been stored or routed successfully. This makes it easier to investigate a failed run without losing track of an event that still needs attention. Connect domain administration to developer workflows Domain and DNS actions can be useful alongside deployment processes. For example, a workflow can check that a required domain is available before requesting approval, or retrieve domain details for an internal inventory. A separately approved workflow might apply DNS changes after a deployment is ready, then route the result for verification. Keep production changes behind explicit checks and provide a rollback plan for settings that can interrupt traffic. The current listing is centered on domain administration. If you need to automate repository changes, build and release pipelines, cloud resources, logs, or service health checks, verify that a listed node exposes those capabilities before planning a workflow. The category label covers these developer needs broadly, but they are not all represented by the current listing. Separate domain lookups from changes Availability checks, domain lookups, and DNS reads help a workflow gather information. Registration, renewal, transfer, forwarding, contact, and DNS write actions change account or domain state. Keep those steps distinct so a lookup result does not trigger a purchase or a configuration change without review. A name reported as available can still require additional registration details or agreements before purchase, and DNS settings shown by an API may not match what external users see immediately because of resolver caching. When a workflow does make a change, retain the domain name, operation result, and time of the request for later review. For an asynchronous transfer or restoration process, do not treat submission as completion; check the status or notification available for that operation. If the response is unclear, stop and inspect the current domain state before retrying an action that could have billing or ownership effects. Keep domain events traceable Use a consistent domain identifier when passing results between workflow steps. For notification handling, keep the notification identifier with the record or task that receives it, and acknowledge it only after the workflow has completed the intended handoff. If a run fails between retrieval and acknowledgment, a later run should be able to find and safely process the unhandled item. These details are useful when domain activity affects deployments or customer-facing services. A record of the change, its approval, and its result can help a developer identify whether a DNS update, forwarding rule, or renewal step is connected to an incident or planned release. Authentication and installation details The current listing describes API actions that require an authorization token with suitable permissions. However, its setup note says the published package does not define an n8n credential field for sending that token. Until the package adds working authentication support, users cannot rely on its protected actions against an account. Check the listing for an update to this limitation before installing or designing a workflow around the operations. The listing shows npm provenance, which links a package release to its source and build record. Provenance is separate from n8n verification. It currently says the node requires self-hosted n8n because n8n Cloud installs only community nodes verified by n8n. Review the latest package notes and installation status before use. Use domain and infrastructure workflows carefully Store API credentials in n8n's credential settings when the node supports them, and grant only the access needed for the workflow. Limit who can edit workflows that register domains, change contacts, modify DNS, or manage transfers. Avoid putting tokens or sensitive account data in execution logs or notifications. Test read operations before write operations. For DNS, compare the current record with the intended value and keep a record of changes. For registration or renewal, check the name and price before any action that may charge the account. For transfers and contact updates, confirm the relevant domain and account permissions. Add error handling and a review path so a failed or ambiguous response does not lead to repeated changes. Build a developer tools node with NativeShip If you build a developer platform or infrastructure service and want n8n users to connect it to their workflows, NativeShip can help you create and publish a community node. Try NativeShip .

HR & Recruiting nodes connect n8n workflows with the systems used to manage employees, hiring, attendance, time off, and people operations. They can help keep staff records in sync, move applicant information through a hiring process, prepare HR reports, or route an employee request to the next step. Each node exposes its own actions and access rules, so check the listing before relying on a particular operation. The current category includes nodes for employee and employment records, applicant tracking, job postings and applications, leave and attendance, performance and engagement data, and HR reports. Some listings also expose compensation or finance records, but the current category does not provide an end-to-end payroll run or payslip workflow. Recruiting coverage and write actions vary: some listings can create applications or job postings, while others focus on retrieving candidate, application, or open-position data. What HR & Recruiting nodes can help you do Organize applicant tracking and recruiting workflows Recruiting actions can help a workflow retrieve candidates, applications, job categories, and open positions. Where the listing supports it, a workflow can also submit an application or create a job posting. This can connect a recruiting form or another approved source of candidate information to the hiring process, or send open-role details to a review step. The available actions differ by integration. Some operations write an application or posting; others only read recruiting data. Confirm which fields are required, whether a candidate or posting already exists, and what access the connected account grants. For decisions such as screening, ranking, or rejecting candidates, keep the hiring team involved and apply the organization's review process rather than treating an automated field or score as the decision. Keep employee and employment records in sync HRIS actions can retrieve, create, or update employee records and employment details. Depending on the listing, they may also expose departments, legal entities, organizational units, employee supervisors, job positions, or project membership. A workflow can use these records to keep an internal system aligned after an approved hire, role change, or departure. Before writing an employee record, identify the person using a stable ID or another reliable key and confirm the fields the service expects. Different systems may use distinct names for the same concept, such as department, position, employment status, or start date. Map those fields deliberately and avoid overwriting information that HR maintains as the source of truth. Some lists are paginated or filtered by account permissions, so a partial result should not be treated as a complete employee directory. Handle attendance, shifts, and time off Attendance and leave operations can help record or retrieve shifts, attendance periods, and absence requests. Depending on the node, a workflow may create or update an attendance period, clock an employee in or out, create a leave request, or list existing leave records. This can help route an absence request, prepare a time report, or pass approved attendance information to another process. Time data needs consistent dates, time zones, and employee identifiers. Check the service's rules for overlapping shifts, required start and end times, and half-day leave before creating or changing a record. A workflow should distinguish a request from an approved absence when the connected service exposes that status. Keep approval with the responsible manager or HR process, and avoid using an automated sync to bypass it. Work with performance and employee engagement data Some current listings focus on performance, engagement, recognition, and employee feedback. Available actions include retrieving survey questions or responses, reading engagement profiles, submitting recognition, managing review presets, listing performance feedback, or downloading appraisal and workplace reports. These actions can help HR teams prepare a report or move an approved recognition or review task into the right workflow. The information returned may include personal context, reviewer feedback, or survey responses. Limit the fields and recipients to what the workflow needs. If a listing supports sending recognition or submitting a performance action, check the required permissions, eligible participants, review cycle, and any supporting information before using it. A successful API response confirms that an action was accepted; it does not replace the organization's review or approval process. Check compensation and payroll coverage carefully Some HR systems expose compensation records, finance accounts, or related employee data. Those records can support a report or a downstream administrative process when the account has the required permissions. The category's current listings do not provide a complete payroll workflow for calculating wages, running payroll, issuing payslips, or filing payroll taxes. If you need one of those actions, check the node's operation list and the service's API documentation rather than assuming compensation data includes payroll processing. Connect HR updates to the next step An HR workflow often spans more than one action: receive a request, look up the employee, check the relevant record, route it for approval, then update a system or notify the right person. Use the record ID and the result from each step to keep the chain connected. For recurring syncs, account for pagination and repeated records so one employee is not processed twice or skipped after a failed run. Choose write actions deliberately. Creating, updating, or deleting an employee record can affect downstream access and reporting. Some systems archive a person while preserving history; others expose a delete action. Read what the operation does, use a review or approval step for consequential changes, and keep an audit trail of which workflow changed the record and why. Access, privacy, and setup Employee and applicant records are sensitive. Use credentials with only the permissions required by the workflow, restrict who can edit or run it, and avoid sending personal details to broad channels or logs. Test mappings with sample or limited records before syncing a full directory. Review how long n8n execution data is retained when it contains applicant details, attendance, compensation, or performance feedback. The current category listings use different authentication methods, including OAuth applications, API keys, and bearer access tokens. Some require an administrator to create credentials, grant scopes, enable developer access, or use an eligible account plan. One current listing notes that its access token expires after 24 hours, so ongoing workflows may need a refresh process. Check each listing for credential setup, permissions, plan requirements, pagination, and operation-level caveats. The current listings show npm provenance, which links a package release to its source and build record. Provenance is separate from n8n verification. They currently indicate that the community nodes require self-hosted n8n because n8n Cloud installs only community nodes verified by n8n. Review each listing for current installation and compatibility details. Build an HR node with NativeShip If you build an HRIS, applicant tracking, payroll, or recruiting service and want n8n users to connect it to their workflows, NativeShip can help you create and publish a community node. Try NativeShip .