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.A useful integration needs visible failures and recoverable delivery.
Keep these details close to the workflow design:
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.
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.
What can Drupal and n8n do together?
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.
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.
- 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.
In this article:
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.
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.
How do webhooks and APIs connect the two systems?
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.
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.
n8n calls the HTTP interface, not the PHP Entity API.
Drupal’s core JSON:API
module exposes HTTP resources around the site’s entity and field
model.
How can a Drupal form create or update a CRM record?
From Drupal to n8n, Drupal sends an HTTP request
when a configured event occurs. The Webhook node receives the payload
and starts a workflow.
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.
Choose the outgoing Drupal
component
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.
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.
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.
Map fields around the
business outcome
| Drupal input | Proposed processing in n8n | Destination |
|---|---|---|
| Contact email | Normalize according to agreed rules and find a match | CRM contact |
| Product interest | Map the value to an external product reference | CRM inquiry or opportunity |
| Inquiry type or region | Select the agreed branch | Sales queue or support system |
| Submission identifier | Retain a stable integration key | Duplicate prevention and delivery tracking |
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
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 the visitor’s wait short
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.
How can an external event create or update Drupal content?
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.
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.
Use JSON:API for
entity-based requests
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.
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.
POST /jsonapi/node/articleto create an article.PATCH /jsonapi/node/article/{uuid}to update an
existing article.
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.
Keep local validation, content rules, and publication authority in
Drupal. Use n8n for cross-system transformation and coordination.
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
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.
You won’t need every module listed below. Select the components that
fit each connection.
The useful event is “became published,” not simply “someone saved the
article.” Draft saves and unrelated edits shouldn’t repeatedly trigger a
launch notification.
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.
Treat publication as a
separate decision
You don’t need a special Drupal connector for these examples. n8n’s
standard Webhook
and HTTP
Request nodes provide the connection paths.
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.
A small mapping makes the distinction clear:
Two Drupal concepts play different roles:
How can Drupal changes trigger work in other 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.
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.
Select and send the event
in Drupal
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.
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.
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.
Three patterns cover many everyday needs:
Send enough context to act
safely
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.
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.
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.
Why does Drupal’s entity model make integrations reusable?
For a broader look at planning these connections, read CMS
integration with external systems and databases – what you need to
know.
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.
- Entity API is Drupal’s internal programming model
for entities. - JSON:API is an HTTP interface built around Drupal’s
Entity and Field APIs.
Choose an allowed body text format too, and validate incoming markup
rather than trusting external HTML.
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.
Creation, updating, and publication are different actions.
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.
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.
Which component does which job?
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.
| Need | Drupal side | n8n side |
|---|---|---|
| Send a Webform inquiry | Webform Remote Post handler | Webhook and downstream actions |
| Send custom form values | Submit handler and integration service or queue | Webhook |
| React to a content event | Configured ECA flow or custom hook and queue | Webhook and routing |
| Read or write content | Core JSON:API with appropriate access | HTTP Request |
| Perform a narrow business action | Custom endpoint with validation and authorization | HTTP Request |
| Coordinate external destinations | Defined event payload | Branches and supported connectors or APIs |
What keeps the workflows dependable?
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.
- 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.
For an Article content type, typical operations are:
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 Entity API doesn’t broadcast webhooks automatically. The
event selection, payload, sender, and delivery handling all need
wiring.
The most useful integrations remove a specific handoff: someone
downloading submissions, copying article text, or notifying another team
after publication.





