Resources · n8n integration

Drift n8n integrationAutomate Drift with n8n.

The Drift n8n integration puts contact management inside your workflows. The node ships with a single resource, Contact, and 5 operations that create, read, update or delete a record and pull its custom attributes. Drift has no trigger node, so another step starts the run.

Verified Trustpilot reviews · AI, automation & growth agency

Why automate

What does the Drift n8n integration actually do?

The Drift n8n integration wires the Drift contact database into workflows you already run in n8n. One node, one resource called Contact, 5 operations: create a contact, read one, update it, delete it, and pull the custom attributes attached to it. n8n carries the authentication and the field mapping, so a Drift record can be built from a form, a spreadsheet row or another tool without writing code.

Contacts created where they actually appear. Signups rarely land in Drift first. They land in a form, a webinar list, a partner file. Drop that source in a workflow, add the Drift node on contact.create, and every new line turns into a Drift contact with its email, and its name and phone when the source carries them. A Google Sheets tab filled by the sales team is enough to feed the whole thing.

A record that stays current. Phone numbers change, people switch companies, and a contact captured months ago drifts away from reality. With contact.get you read the record, with contact.update you push the corrected values back. Run it from the deal owner's update in Pipedrive and the chat side stops showing a stale name.

Cleanups that reach the end. Erasure requests, duplicates, test records from a demo week: contact.delete takes one identifier and removes one record, which makes it easy to loop over a reviewed list rather than clicking through an interface. Post the result in Slack and the person who asked for the cleanup sees it happen.

The node covers the Contact resource. Anything else in the Drift API is reachable through the HTTP Request node, which calls any endpoint of the tool and reuses the same credential through predefined authentication. That is the normal way to extend a dedicated node, not a workaround.

One thing to plan for: Drift has no trigger node in n8n. A workflow around it starts somewhere else, with a Schedule Trigger firing at a fixed interval, with an n8n Webhook called by another service, or with the trigger of another tool. If you want the wider picture on where n8n fits before building this, the n8n review goes through it.

Connect

How do you connect Drift to n8n?

  1. 01

    Create and install the Drift app

    Authentication starts on the Drift side. Create a Drift account if the team does not have one yet, then create a Drift app and install it to that Drift account. Installing the app is what generates the OAuth access token, and that token is the value n8n will ask for later. Nothing happens in n8n at this stage, so keep the token somewhere safe while you switch tabs.

  2. 02

    Add the credential in n8n

    Open the Credentials menu in n8n and pick the Drift credential. Two authentication methods are supported. The API personal access token: paste the token generated by the installed app into the Personal Access Token field. Or OAuth2: run the web flow described in Drift's authentication and scopes documentation. A credential is created once and reused by every workflow that talks to Drift.

  3. 03

    Point the node at a contact

    Add the Drift node to a workflow, select the credential from the dropdown, then choose the Contact resource and one of the 5 operations. Fields marked as required block the execution when they are empty, so any operation working on an existing record needs its Contact ID first. Values coming from an earlier step are mapped with an expression, written {{ $json.field }}.

Actions

What can the Drift node do?

The Drift node exposes 5 operations across 1 resources. For each one: the node as you configure it in n8n, the required fields, and our field notes.

Resources × operations matrix
ResourceCreateGetUpdateDeleteCustom Attributes
Contact✓✓✓✓✓

Contact

5 operations
01

Create a contact

contact.create

What you see in n8n

Notes & use cases

Adds a contact to Drift from the data flowing into the node, so the record exists on the chat side without anyone retyping it.

Key parameters

  • Email: the email of the contact, required, in the name@email.com shape shown by the placeholder; it usually comes from the previous step through an expression such as {{ $json.field }}.
  • Additional Fields: an optional collection holding Name and Phone, worth filling when the source already carries them.
Use cases
a demo request arrives with an email and a phone number, and the workflow creates the Drift contact before the first reply goes out.
02

Get custom attributes for a contact

contact.getCustomAttributes

What you see in n8n

Notes & use cases

Drift contacts can carry custom attributes on top of the standard ones. This operation reads them and hands them to the next step. The node asks for nothing else: pick the Contact resource, pick the operation, run it. Whatever comes back is available in the item, and you read it with a generic expression like {{ $json.field }} once you have seen the shape of one execution.

Use cases
before a contact is mirrored into HubSpot, this step shows which attributes exist on the Drift side and which of them deserve a column in the destination.
03

Delete a contact

contact.delete

What you see in n8n

Notes & use cases

Takes one contact out of Drift. The operation works on a single record at a time, which fits a loop over a reviewed list far better than a bulk button would.

Key parameters

  • Contact ID: the unique identifier for the contact, required. It is rarely typed by hand: it arrives from an earlier step as an expression, written {{ $json.field }}.
Use cases
a monthly list of erasure requests runs through the node one row at a time, and each request ends with the Drift record gone instead of flagged.
04

Get a contact

contact.get

What you see in n8n

Notes & use cases

Reads one Drift contact and passes it on, which is what you want before deciding anything: branch on what the record says, enrich it, or simply check that it still exists.

Key parameters

  • Contact ID: the unique identifier for the contact, required. The node expects that identifier, not the person's name or address, so a workflow that only knows an email has to resolve the id first.
Use cases
a support ticket carries a Drift identifier, and the workflow pulls the contact to route the ticket to the right owner.
05

Update a contact

contact.update

What you see in n8n

Notes & use cases

Writes new values onto a contact that already exists in Drift, instead of creating a second record next to the first one.

Key parameters

  • Contact ID: the unique identifier for the contact, required, since the operation needs to know which record it is editing.
  • Update Fields: an optional collection with Email, Name and Phone; fill the ones you want to change.
Use cases
a lead moves from a personal address to a company one, and the workflow puts the new email on the Drift record the same day.
Need help

Need help automating Drift with n8n?

A person reads every message.

FAQ

Drift and n8n: common questions

01Is the Drift n8n integration free?
Yes on the n8n side. The Drift node ships with n8n, so there is nothing to install and nothing extra to pay for the connector itself. It behaves the same on n8n Cloud, the hosted offer run by n8n, and on a self-hosted instance installed with Docker or npm under the Community Edition and its Sustainable Use licence. A workflow built in one place runs the same way in the other, which matters if you prototype on Cloud and move to your own server later. What a Drift account costs is a separate question, handled by Drift and not by the node.
02What credentials do you need for Drift in n8n?
Two methods are supported: an API personal access token, and OAuth2. For the token route, you create a Drift account, create a Drift app, then install that app to the account, which is what generates the OAuth access token you paste into the Personal Access Token field of the n8n credential. For OAuth2, the setup follows Drift's authentication and scopes documentation. Either way the credential lives in the Credentials menu of n8n, gets created once, and is offered in the dropdown of every Drift node you add afterwards, including any HTTP Request node using predefined authentication.
03What are the limits of the Drift node?
It covers one resource and 5 operations, all on the Contact object: create, get, update, delete, and get custom attributes. That is the scope of the dedicated node. Anything outside those catalogue operations goes through the HTTP Request node, which calls any endpoint of the Drift API and reuses the same credential through predefined authentication, so you do not manage a second set of keys. In practice a workflow often mixes both: the Drift node for the contact lifecycle, one HTTP Request step for the rest, with the same data flowing between them.
04Can a workflow react to Drift in real time?
Not from Drift itself. There is no Drift trigger node in n8n, so a workflow touching Drift starts somewhere else. Three usual options: a Schedule Trigger that runs at a fixed interval and walks a list, an n8n Webhook, meaning a URL n8n exposes that another service calls when something happens on its side, or the trigger of another tool already in your setup, such as a form or a CRM. The Drift node then runs as an action inside that workflow, which is enough for most contact work since the record rarely needs to change the same second.
05n8n or Make for Drift?
It depends on where you want the workflow to live. Make is a hosted automation platform, with no self-hosting option, billed per operation. n8n runs on Cloud or on your own server, so the data passing through a contact workflow can stay on infrastructure you control, and the cost model follows that choice rather than the number of steps executed. Both give you visual logic. If your Drift work stays at a few contact operations a day, either fits; if it grows into long loops over lists, the per-operation count starts to weigh on one side and not the other.