HubSpot n8n integrationAutomate HubSpot with n8n.

Creates a company record and returns it, so the nodes that follow can attach contacts or deals to the new account.

• Name: the only required field, usually an expression such as {{ $json.company }}, which reads a field from the item coming in.
• Company Properties: an optional collection of 34 fields, from Company Domain Name and Industry Name or ID to Annual Revenue and Number Of Employees, with Custom Properties for whatever your portal added.

The account leaves the CRM for good. Nothing gets restored afterwards, so this operation usually sits behind a filter or a human approval step.

• Company to Delete: a resource locator, so you either pick the company from the list or pass its ID from the previous node.

Reads one company and its properties, the usual second step once a company event has fired.

• Company to Get: the company, picked from the list or resolved from the incoming item.
• Include Merge Audits: false by default; switch it on to get the merge history when the record was previously merged with another company.

Lists companies, page after page of them when Return All is on.

• Return All: on, n8n walks every page of companies; off, Limit caps how many come back.
• Company Properties to Include: name the properties you actually need, or the export weighs more than the sheet receiving it.
• Include Merge Audits: adds the merge history of each company that went through a merge.

Same list, narrowed to what moved: the companies created or updated since a moment you choose.

• Since: returns only companies created after that timestamp; inside an expression the format is YYYY-MM-DD hh-mm-ss.
• Return All: off, the run stops at Limit, which keeps a nightly catch-up predictable.

Search means one thing here, the website domain, because that is the property HubSpot uses to tell companies apart.

• Domain: required, the website domain to look for, like n8n.io, most often the part of the lead's address after the at sign.
• Return All: one domain can match several records; off, Limit decides how many you keep.
• Company Properties to Include: the fields returned with each match, worth setting when the next node needs more than an identifier.

Changes values on an existing company and leaves every other field alone.

• Company to Update: the record to write on, from the list or from the incoming item.
• Update Fields: 35 fields, one more than on create, because Name becomes editable here; Lifecycle Stage Name or ID and Lead Status Name or ID are the two that move a process forward.

One node instead of a search and a branch: the contact is created, or updated when the email already exists.

• Email: required, and the value HubSpot matches on to decide between create and update.
• Contact Properties: 67 fields, among them First Name, Last Name, Job Title, Lifecycle Stage Name or ID and Associated Company Name or ID to link the person to an account.
• Simplify Output: the response carries only the ID unless you turn this on, which resolves the contact data instead.

Erases a contact from the CRM.

• Contact to Delete: the contact ID, a number like 1485 and not an email address; when the address is all you have, run the search operation first and pass the ID it returns.

Reads one contact. By default the answer holds the Contact ID and nothing else, which catches everyone out the first time.

• Contact to Get: the numeric contact ID again, never the email.
• Contact Properties to Include: name every property you want back, several of them separated by a comma; without it there is no value to read.
• Include List Memberships: adds the lists the contact currently belongs to.
• Form Submission Mode: All, None, Newest or Oldest, to choose which form submissions travel with the record.

Walks the contact database, all of it or the first slice.

• Return All: on for a real export, off to stop at Limit while the workflow is still being built.
• Contact Properties to Include: same rule as a single read, no property named means no property returned.
• Include List Memberships: worth the extra weight when the export has to show which segment each person sits in.

Recent contacts, created or updated. Unlike the company and deal versions of this operation, it has no Since option, so the cut-off has to come from how often the workflow runs.

• Return All: off, Limit keeps each scheduled run to a size you can reason about.
• Form Submission Mode: Newest is the practical setting when the point is to see what someone just submitted.

Queries contacts on their property values and hands back the matches.

• Filter Groups: filters inside a group combine with AND, groups combine with each other using OR; three groups of three filters is the ceiling.
• Query: a plain text search across all property values, for when you do not know which field holds the term.
• Sort By and Sort Order: results come back Descending unless you ask for Ascending.
• Return All: off, Limit caps the result set.

Puts a contact into a HubSpot list, which is how most nurture sequences get their audience.

• By: Contact ID or Email, the two ways of designating the person.
• Email: the address, when By is set to Email.
• Contact to Add: the numeric ID, when By is set to Contact ID.
• List to Add To: the list, given as a number and not as its name.

Membership ends, the record stays: the person leaves the list and nothing else about the contact changes.

• Contact to Remove: the numeric contact ID, with no email shortcut here, unlike the add operation.
• List to Remove From: the list the person leaves.

Opens a deal in the pipeline and returns it.

• Deal Stage Name or ID: required, the stage the deal starts in, chosen from the list or passed as an ID.
• Deal Properties: 10 optional fields, among them Deal Name, Amount, Close Date, Pipeline Name or ID, Deal Owner and Associated Vid Names or IDs to attach the contacts involved.

Takes a deal out of the pipeline permanently. The forecast recalculates without it, which is exactly the point when the deal was never real.

• Deal to Delete: the deal, selected in the list or passed as an ID from the node before it.

Pulls one deal with the properties you asked for. Same rule as contacts: no property named, no value returned.

• Deal to Get: the deal to read.
• Deal Properties to Include: the properties added to the result, requested again for each extra one.
• Include Property Versions: off, you get the current value; on, you get every previous version of that property.

Every deal, or the first page of them, with the option of bringing the linked records along.

• Return All: on for the whole pipeline, off to stop at Limit.
• Include Associations: returns the IDs of the contacts and companies tied to each deal, and the associated contact count with them.
• Deal Properties with History to Include: like the property list, but each value arrives with its history.

Deals that moved since a given moment, created ones and updated ones together.

• Since: the cut-off; written in an expression, the timestamp follows the YYYY-MM-DD hh-mm-ss format.
• Include Property Versions: adds the earlier values of each property, which is how you spot a stage that moved twice in the same day.
• Return All: off, Limit holds the run down while the workflow is being tested.

Where contact search looks for people, this one narrows the pipeline: the deals matching the conditions you set.

• Filter Groups: how you express a stage and an amount in the same condition, three groups at most, three filters each.
• Field Names or IDs: the deal properties returned with every match.
• Direction: Ascending or Descending, Descending being the default.
• Query: a text search run over all property values.

The node that moves a deal forward: it writes on an existing record without touching the rest of it.

• Deal to Update: the deal to write on.
• Update Fields: 9 fields, Deal Stage Name or ID among them, so the same node that closes a deal can set its Amount and its Close Date.
• Pipeline: a plain text field here, where the create operation offers a list to choose from.

An engagement is HubSpot's name for a logged activity, and this operation creates one from a workflow.

• Type: required, and the four choices are call, email, meeting and task.
• Metadata: the optional collection carrying the content, with Subject and Body for the text, Status for a task (NOT_STARTED, IN_PROGRESS, WAITING, COMPLETED, DEFERRED) and For Object Type to hang it on a CONTACT or a COMPANY.
• Associations: sits in the same collection and links the activity to existing records.

Takes a logged activity back out of HubSpot. Handy when a run created the wrong one, or when two branches of the same workflow recorded the same call twice.

• Engagement to Delete: a resource locator, so you either pick the activity from the list or pass its ID through an expression, n8n's way of reusing a value produced by an earlier node.

The logged activity comes back whole, content included, so the nodes that follow work on what was actually recorded instead of a guess.

• Engagement to Get: a resource locator that accepts a pick from the list or an ID from a previous step. Nothing else is asked for.

Returns activities in bulk rather than one by one, which is how a whole month of calls, emails and meetings lands in a single execution.

• Return All: switched on, n8n keeps asking HubSpot for the next page until every activity is back. Switched off, it stops at Limit.
• Limit: the maximum number of activities handed to the next node, the sane setting while the workflow is still being tested.

Opens a support ticket in a chosen pipeline and at a chosen stage. Three fields are required, and 10 more sit in an optional collection.

• Pipeline Name or ID: required, the pipeline the ticket lands in, from the list or as an ID.
• Stage Name or ID: required, and its options depend on the pipeline, so pick that first.
• Ticket Name: required, the title the support team reads.
• Ticket Properties: optional, the ones worth setting being Description, Priority Name or ID, Ticket Owner Name or ID and Contact Names or IDs.

Deletes a ticket outright. The node asks for the ticket and for nothing else, so the condition that decides whether it really should go belongs earlier in the workflow.

• Ticket to Delete: a resource locator, chosen from the list or passed as an ID coming out of the node before.

This operation pulls one ticket back, and it is the only ticket read that can surface a deleted one.

• Ticket to Get: required, a resource locator, from the list or as an ID.
• Include Deleted: optional switch that lets a deleted ticket come back in the result.
• Ticket Properties to Include: names the ticket properties you want in the result.
• Properties With History: returns the full history of changes for the property you name, instead of its current value alone.

Lists tickets instead of fetching them one at a time, with the same properties options as the single read, plus pagination.

• Return All: every ticket comes back, page after page. Left off, Limit decides how many do.
• Ticket Properties to Include: keeps the output to the ticket properties the next nodes actually use.
• Properties With History: adds the change history of the property you name to each ticket returned.

Changes a ticket that already exists. The optional collection holds 13 fields, so one ticket can be moved, reassigned and closed by different branches of the same workflow.

• Ticket to Update: required, the resource locator pointing at the ticket to change.
• Stage Name or ID and Pipeline Name or ID: optional here, and together they move the ticket across the board.
• Ticket Owner Name or ID: hands the ticket to someone else on the team.
• Close Date: a date field. In an expression, the format is YYYY-MM-DD hh-mm-ss.