Drupal and n8n integration: connect forms, content, and business systems

Suppose a visitor submits a product inquiry on your website. With a Drupal n8n integration, the submission could reach your CRM, notify the right sales team, and return a reference for follow-up. Your team would spend less time copying data and more time responding.

The connection works in reverse, too. An approved article in another system could become a Drupal draft, while a changed event date could update an existing page.

Drupal provides forms, structured content, validation, and publication controls. n8n routes and transforms data between systems. Together, they can connect your website to the work that happens before and after a page visit.

In this article:

• What can Drupal and n8n do together?
• How do webhooks and APIs connect the two systems?
• How can a Drupal form create or update a CRM record?
• How can an external event create or update Drupal content?
• How can Drupal changes trigger work in other systems?
• Why does Drupal’s entity model make integrations reusable?
• Which component does which job?
• What keeps the workflows dependable?

What can Drupal and n8n do together?

The most useful integrations remove a specific handoff: someone downloading submissions, copying article text, or notifying another team after publication.

Three patterns cover many everyday needs:

• Forms to business systems: send an inquiry to a CRM, route a support request, or register someone for an event.
• External systems to Drupal: create a draft from approved source material or update a product specification.
• Drupal to external systems: notify a team when content becomes public or send changed information to an external catalog.

Each pattern needs field mappings and agreed rules. Connecting the systems won’t automatically decide which CRM record to update or who can publish an imported article.

Ownership stays explicit. Drupal can remain the source of truth for website content, while a CRM owns customer records and a PIM owns product specifications. n8n coordinates the handoffs rather than becoming another content repository.

For a broader look at planning these connections, read CMS integration with external systems and databases - what you need to know.

How do webhooks and APIs connect the two systems?

You don’t need a special Drupal connector for these examples. n8n’s standard Webhook and HTTP Request nodes provide the connection paths.

From Drupal to n8n, Drupal sends an HTTP request when a configured event occurs. The Webhook node receives the payload and starts a workflow.

From n8n to Drupal, the HTTP Request node calls a Drupal API to read, create, or update records within the integration account’s permissions. When a source system cannot send events, n8n can also retrieve records on a schedule.

Drupal form or content event
  → n8n webhook → processing and routing → CRM / helpdesk / other API

External event or approved content
  → n8n workflow → Drupal JSON:API → new or updated content

Receipt isn’t completion. A webhook response may confirm that n8n accepted a request, while a later CRM action could still fail. Track the HTTP exchange and the final business outcome separately.

How can a Drupal form create or update a CRM record?

Suppose your inquiry form collects contact details, a message, product interest, and region. The proposed workflow will validate the submission in Drupal, send selected values to n8n, and look for a matching CRM contact.

If a match exists, n8n will update the permitted fields and attach the inquiry. Otherwise, it will create the appropriate record. An agreed routing rule will then send the inquiry to a regional sales queue or create a support ticket.

Choose the outgoing Drupal component

For forms built with the contributed Webform module, its Remote Post handler provides a straightforward outgoing-request path. The handler belongs to Webform; it isn’t part of Drupal core’s Form API. Check your installed version’s options before deciding on payload and authentication details.

The optional Webform Remote Handlers project provides REST/SOAP handlers with payload and authentication configuration. Treat it as an alternative for relevant requirements, not a dependency for every integration.

For a custom Drupal form, a submit handler can pass validated values to an integration service or queue. Existing entity forms may be easier to connect through entity events than by modifying every form.

Map fields around the business outcome

Agree on ambiguous cases early. If a lookup returns several contacts, the workflow can send the inquiry to a person for review rather than guessing. Marketing preferences also need explicit mapping: submitting a sales inquiry doesn’t automatically mean subscribing to campaigns.

A stable submission identifier lets the destination recognize a repeated delivery. That matters when a timeout prompts a retry after the CRM has already saved the record.

Keep the visitor’s wait short

For multi-step work, background delivery will avoid making the visitor wait for every connected system. A durable queue and retry behavior need implementation; a Remote Post handler alone doesn’t establish that architecture.

You can also return the CRM reference to a purpose-built Drupal endpoint or another permitted record. Don’t assume that core JSON:API exposes every Webform submission element for write-back. Outbound delivery doesn’t depend on that capability.

How can an external event create or update Drupal content?

Suppose an external editorial system marks an article as approved. n8n will receive the event, retrieve the source record, map its fields, and create a Drupal Article draft. An editor will review the imported content before publication.

The same pattern can update existing content. An event platform might own event dates, for example, while Drupal owns the website introduction and related links. A date change should update the date fields without overwriting the editor’s introduction.

Use JSON:API for entity-based requests

Drupal’s core JSON:API module exposes HTTP resources around the site’s entity and field model.

For an Article content type, typical operations are:

• POST /jsonapi/node/article to create an article.
• PATCH /jsonapi/node/article/{uuid} to update an existing article.

These resource names depend on the site’s actual model. The n8n HTTP Request node sends authenticated requests; Drupal still applies validation and access checks.

JSON:API defaults to read-only. Writes need deliberate enablement, authentication, and an account with limited permissions. Enabling writes alone doesn’t make an integration secure. We cover exposing Drupal data over APIs in more detail in Headless CMS: how to expose data using REST API and JSON API modules.

Store an external source identifier in an agreed field or mapping record. On later runs, n8n will use that identifier to locate the Drupal entity and obtain its UUID. Otherwise, each source update could become another article.

Separate attributes from relationships

A small mapping makes the distinction clear:

External title       → attributes.title
External body        → attributes.body.value
External source ID   → attributes.field_source_id
External category   → relationships.field_tags
External image      → relationships.field_image

The custom field names here are illustrative.

Attributes hold field values. Relationships point to other entities, such as taxonomy terms or media. Those referenced entities need to exist, and the workflow needs their resource types and UUIDs. An article POST won’t automatically create a missing term or upload an image into a media entity.

Choose an allowed body text format too, and validate incoming markup rather than trusting external HTML.

Treat publication as a separate decision

Creation, updating, and publication are different actions.

With Drupal’s core Workflows and Content Moderation modules enabled, the integration needs to respect configured states, transition permissions, and review rules. Changing status isn’t a universal shortcut around moderation.

Automatic publication can make sense for authorized, validated updates, such as an event date from its authoritative source. Imported editorial copy may need a human checkpoint. Agree on that boundary per workflow.

For a narrow action involving several entities, a custom endpoint can be clearer than several general-purpose writes. It still needs explicit authorization and validation.

How can Drupal changes trigger work in other systems?

Suppose publishing an article needs to notify a communications team and update an external catalog. Drupal will send a publication event to n8n, which will route the relevant data to each destination.

The useful event is “became published,” not simply “someone saved the article.” Draft saves and unrelated edits shouldn’t repeatedly trigger a launch notification.

Select and send the event in Drupal

The contributed ECA module lets teams model events, conditions, and actions. An ECA flow can identify the relevant change and invoke an outgoing-request action available in the installed integration stack.

Check the plugins and versions before planning the exact configuration. HTTP Client Manager is a contributed option for reusable external HTTP operations and appears in the ECA ecosystem. It isn’t mandatory for every outgoing request, and available actions vary by setup.

A custom module offers another route: entity insert or update hooks can enqueue an event, and a worker can send it using Drupal’s HTTP client. This approach is useful when the project needs explicit retry logic or carefully defined transition detection.

Drupal’s Entity API doesn’t broadcast webhooks automatically. The event selection, payload, sender, and delivery handling all need wiring.

Send enough context to act safely

A practical event payload includes an event identifier, entity UUID, event type, and the fields the destination needs. n8n can fetch additional permitted data if necessary.

The editor’s publication decision can serve as the human checkpoint. If downstream work includes sending a campaign, a separate approval may still be appropriate.

Also prevent round trips. When n8n writes an external reference back to Drupal, that update shouldn’t start the same workflow indefinitely. Conditions can check relevant field changes and integration-origin markers.

Why does Drupal’s entity model make integrations reusable?

Defined fields save you from extracting business data from page markup. A workflow can read a date field, product reference, or category directly instead of guessing where it appears in rendered HTML.

Two Drupal concepts play different roles:

• Entity API is Drupal’s internal programming model for entities.
• JSON:API is an HTTP interface built around Drupal’s Entity and Field APIs.

n8n calls the HTTP interface, not the PHP Entity API.

Once you have authentication, identifier mapping, and error handling in place, another clearly modeled content type can reuse that integration pattern. Actual operations still depend on entity support, permissions, and any translation or revision requirements.

This structure also helps in the LLM era. Consistent fields can supply web pages, feeds, APIs, and structured metadata, reducing contradictory information across channels. Integrations can keep source facts current, though they don’t guarantee that AI assistants will discover or recommend your website.

An AI step is optional. n8n could classify an inquiry or prepare a draft with approved data handling and suitable review. Moving a validated form submission into a CRM doesn’t need an LLM.

Keep local validation, content rules, and publication authority in Drupal. Use n8n for cross-system transformation and coordination.

Which component does which job?

You won’t need every module listed below. Select the components that fit each connection.

What keeps the workflows dependable?

A useful integration needs visible failures and recoverable delivery. Keep these details close to the workflow design:

• Protect credentials. Use separate, least-privilege integration accounts, authenticated webhooks, and HTTPS. Store secrets in n8n’s credential facilities or an approved secret store, not payloads or exported workflow text. Plan rotation.
• Limit personal data. Send only required fields and set execution-log retention deliberately. Failed runs can contain submitted messages and contact details.
• Make retries safe. Use stable identifiers, duplicate checks, and bounded retries. Track each destination separately so retrying a failed notification doesn’t create another CRM inquiry.
• Monitor the automation. Assign an owner, alert on failed or stalled executions, and check that scheduled workflows actually run. A successful webhook receipt doesn’t prove downstream completion.
• Respect editing boundaries. Limit inbound updates to fields the source owns. Detect or route conflicts for review when an editor has changed the same content.

These safeguards protect the time you intended to save. For common pitfalls at this stage, see 5 problems you may encounter when integrating Drupal with third-party software.

Connect your website to the work that happens next

Drupal and n8n can connect three practical handoffs: form data reaching business systems, external changes updating website content, and Drupal events initiating downstream work.

Drupal’s defined entities, fields, and publication controls provide the content foundation. n8n connects that foundation to the wider process without taking over content ownership.

Which handoff is costing your team time? Talk with Droptica about the forms, content changes, and business systems you want to connect. We’ll help identify the API paths, field mappings, and review points your workflows will need. You can also learn more about our Drupal development services.