.png)
Drupal Integration Guide
Drupal integrates with enterprise systems through configurable REST and JSON:API endpoints, optional GraphQL, managed files, and site-specific webhook callbacks.
Drupal integration options at a glance
Drupal provides RESTful Web Services and JSON:API through core modules, enabling applications to read, create, update, and delete configured entities subject to permissions. JSON:API supports filtering, sorting, pagination, relationships, and sparse fieldsets, making it suitable for structured content synchronization. GraphQL is available through a contributed module and is dependent on the site-specific schema. Webhook-style callbacks can be supplied by contributed modules or custom Drupal code for selected events, but are not universal. Drupal also exposes Media and File entities through configured resources. Martini can consume these HTTPS APIs, receive confirmed callbacks, schedule incremental polling, transform relationships, and orchestrate downstream workflows.
| Integration point | Supported by Drupal? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Drupal core RESTful Web Services can expose configured resources for GET, POST, PATCH, and DELETE operations, subject to resource configuration, formats, and permissions. | Martini can consume Drupal REST endpoints over HTTPS, map request and response payloads, apply business rules, and orchestrate calls to downstream systems. |
| JSON:API | Yes | Drupal core JSON:API provides standardized collection and individual resource endpoints with filtering, sorting, pagination, relationships, included resources, and permitted mutations. | Martini can retrieve paginated collections, follow relationships, maintain checkpoints, and transform Drupal entity representations into canonical or target models. |
| GraphQL APIs | Limited | The contributed Drupal GraphQL module can expose site-specific queries and mutations. The schema and available operations depend on module and custom configuration. | Martini can consume a configured Drupal GraphQL endpoint when its schema, authentication, and operations are confirmed. |
| Webhooks and outbound callbacks | Not confirmed | Drupal core does not provide universal outbound webhooks. Contributed modules, custom event subscribers, queues, or application code may send selected event notifications. | Martini can receive callback requests through an API or webhook workflow after event types, payloads, signing, and retry behavior are confirmed. |
| Bulk and asynchronous processing | Limited | Drupal has internal batch and queue capabilities, while JSON:API provides pagination; a standardized external bulk mutation API is not guaranteed. | Martini can process paginated or individually submitted resources with bounded concurrency, checkpoints, queue-based orchestration, and retry handling. |
| File and attachment APIs | Limited | Media and File entities can be exposed through REST or JSON:API, but upload behavior, binary transfer, private access, and permissions depend on site configuration. | Martini can retrieve metadata, download or upload binaries where permitted, map Media-to-File relationships, and route private-file handling explicitly. |
| Authentication | Yes | Drupal installations may use session authentication, Basic Authentication through a core module, or OAuth 2.0 through contributed modules such as Simple OAuth. Roles and permissions govern access. | Martini can store credentials and tokens in secure environment configuration and consume Drupal endpoints using the authentication method enabled by the site. |
| Database and analytics access | Not confirmed | Drupal uses a relational database abstraction layer, but direct table access is not the preferred external integration method because entity behavior, access rules, revisions, and relationships may be bypassed. | Martini can use APIs or purpose-built exports instead; database access should be considered only where a controlled reporting interface is explicitly provided. |
How Drupal exposes data and business events
Drupal REST APIs
Drupal core RESTful Web Services exposes configured resources over HTTP. Depending on configuration, clients can retrieve, create, update, or delete entities using JSON or XML representations and the methods permitted for each resource.
Martini implementation pattern
Martini implementation pattern: Martini consumes the configured REST endpoint over HTTPS, authenticates with the Drupal method selected by the installation, validates the response, maps the resource into a canonical model, and invokes downstream APIs or workflows.
Implementation sequence
Drupal JSON:API
Drupal core JSON:API provides a consistent interface for entity collections and individual resources. It supports filtering, sorting, pagination, relationships, included resources, sparse fieldsets, and permitted mutations, but exposure remains dependent on the site configuration and permissions.
Martini implementation pattern
Martini implementation pattern: A scheduled or API-triggered workflow reads JSON:API collections, follows pagination links, resolves relationships and included resources, and uses UUID-based keys to create or update downstream objects idempotently.
Implementation sequence
Drupal GraphQL APIs
Drupal GraphQL is available through a contributed module rather than Drupal core. Its queries, mutations, schema, authentication, and available fields depend on the specific module version and site configuration.
Martini implementation pattern
Martini implementation pattern: Martini consumes the confirmed GraphQL endpoint and operation definitions, maps returned fields into a canonical model, and isolates site-specific queries so schema changes can be tested without disrupting unrelated workflows.
Implementation sequence
Drupal webhook-style callbacks
Drupal core does not guarantee outbound webhooks for all entity changes. Contributed modules, custom event subscribers, queue workers, or application code may send callbacks for selected events, with delivery and signing behavior determined by the installation.
Martini implementation pattern
Martini implementation pattern: Martini exposes an API or webhook endpoint for the Drupal callback, validates authentication or signatures where configured, checks the event and payload, retrieves the current resource when necessary, and performs idempotent downstream processing.
Implementation sequence
Scheduled Drupal synchronization
When a Drupal installation has no suitable outbound event mechanism, scheduled polling of JSON:API or REST resources provides a practical fallback. Filtering, changed timestamps, revisions, and maintained checkpoints can limit the synchronization scope.
Martini implementation pattern
Martini implementation pattern: Martini starts a scheduled workflow, retrieves filtered and paginated resources with bounded concurrency, persists the last successful checkpoint, and retries temporary failures without replaying completed work.
Implementation sequence
Common Drupal integration patterns
Pattern 1: Syndicate Drupal content to search and publishing platforms
When to use this pattern
Use this pattern when Drupal is the editorial source for Articles, Basic Pages, Media, and Taxonomy terms that must be published to a search platform, CDN, or another content experience. Scheduled JSON:API polling is appropriate when the site does not provide reliable outbound events.
Integration direction
Example Mapping
| Drupal Field | Canonical Field | Target Field |
|---|---|---|
| id | sourceEntityId | external_id |
| type | contentType | content_type |
| title | title | title |
| changed | lastModified | updated_at |
Martini implementation pattern
A scheduler starts a Martini workflow that reads filtered, paginated JSON:API collections, resolves Media and Taxonomy relationships, excludes unpublished content according to policy, and upserts indexed documents using entity UUIDs. The workflow stores a checkpoint, limits concurrency, and retries transient API or target failures without duplicating successful writes.
Martini capabilities used
- workflows
- scheduled triggers
- API consumption
- pagination and checkpointing
- data mapping
- business rules
- error handling
Pattern 2: Synchronize Drupal registrations with Salesforce
When to use this pattern
Use this pattern when Drupal collects registrations, contact requests, or profile information that must be validated and represented in Salesforce. The source may be a configured Drupal callback, custom endpoint, or scheduled API read.
Integration direction
Example Mapping
| Drupal Field | Canonical Field | Target Field |
|---|---|---|
| name | fullName | Name |
| created | registrationCreatedAt | CreatedDate |
| uid | sourceUserId | External_Id__c |
Martini implementation pattern
Martini receives or retrieves the Drupal submission, validates required fields and consent, normalizes email addresses, applies routing rules, and performs an idempotent Salesforce upsert using the Drupal user or submission identifier. Permission failures and validation errors are separated from retryable transport failures.
Martini capabilities used
- API endpoints
- workflows
- data validation
- data mapping
- business rules
- API orchestration
- retry handling
Pattern 3: Synchronize Drupal media and files with an external repository
When to use this pattern
Use this pattern when Drupal Media and File entities need to be distributed to a DAM, object store, CDN, or document repository. It is useful when metadata and binary content have different access or processing requirements.
Integration direction
Example Mapping
| Drupal Field | Canonical Field | Target Field |
|---|---|---|
| media.uuid | mediaId | document_id |
| media.name | assetName | name |
| file.uri | sourceUri | source_uri |
| file.filesize | sizeBytes | size |
Martini implementation pattern
Martini reads Media metadata and its File relationship, determines whether the file is public or private, retrieves the binary through an authenticated request when permitted, and writes metadata or content to the target. Stable Media and File UUIDs prevent duplicates, while failed transfers are isolated for retry.
Martini capabilities used
- workflows
- REST and JSON:API consumption
- file handling
- data mapping
- conditional routing
- idempotency
- error handling
Pattern 4: Synchronize Drupal commerce data with an ERP
When to use this pattern
Use this pattern when Drupal Commerce or a custom Drupal application exchanges products, inventory, pricing, customers, orders, or fulfillment information with an ERP such as NetSuite or SAP S/4HANA. The exact object model must be confirmed for the installation.
Integration direction
Example Mapping
| Drupal Field | Canonical Field | Target Field |
|---|---|---|
| sku | productSku | itemId |
| title | productName | displayName |
| price | unitPrice | salesPrice |
| status | publicationStatus | active |
Martini implementation pattern
Martini orchestrates the Drupal and ERP API calls, transforms custom Drupal entities into the ERP model, applies ownership and publication rules, and records correlation identifiers for reconciliation. Rate limits, revision conflicts, validation errors, and temporary ERP failures follow separate handling paths.
Martini capabilities used
- API orchestration
- workflows
- data transformation
- business rules
- correlation tracking
- controlled concurrency
- retry and reconciliation
Applications commonly integrated with Drupal
Drupal is frequently positioned as a content, experience, or application layer alongside enterprise platforms. The exact object coverage depends on the Drupal modules, content model, and APIs enabled on the specific installation.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Synchronize Drupal registrations, contact requests, campaign responses, and customer profile information with Salesforce records. | Drupal → Martini → Salesforce | Martini can receive a Drupal callback or poll a configured endpoint, validate consent and contact fields, map the payload to Salesforce objects, and apply idempotent upsert and retry handling. |
| HubSpot | Send Drupal form submissions and selected engagement data to HubSpot marketing and CRM workflows. | Drupal → Martini → HubSpot | A Martini workflow can consume Drupal REST or JSON:API data, normalize email and consent fields, apply routing rules, and call HubSpot APIs with operational error handling. |
| Shopify | Synchronize product, category, promotional, or editorial information between Drupal and a Shopify storefront where responsibilities are shared across platforms. | Drupal → Martini → Shopify | Martini can read Drupal Nodes, Media, and Taxonomy terms, map them to Shopify resources, and process selected reverse updates with stable identifiers and controlled concurrency. |
| NetSuite | Exchange product, inventory, customer, order, and fulfillment information when Drupal Commerce or a custom Drupal application participates in ERP processes. | Drupal → Martini → NetSuite | Martini can orchestrate bidirectional API workflows, map Drupal entities to NetSuite objects, enforce ownership rules, and route validation or temporary failures for retry. |
| SAP S/4HANA | Synchronize product, customer, pricing, inventory, or order information for enterprise publishing and commerce scenarios. | Drupal → Martini → SAP S/4HANA | A Martini workflow can retrieve configured Drupal resources, transform content and reference data into SAP service models, and coordinate acknowledgements, retries, and reconciliation. |
| Jira | Create or update Jira issues from Drupal support, editorial, or website incident workflows and return selected status information. | Drupal → Martini → Jira | Martini can expose an API for Drupal to call or poll Drupal resources, translate submissions into Jira issue fields, and process Jira status updates through a separate workflow. |
| Mailchimp | Synchronize Drupal newsletter subscriptions and audience membership with Mailchimp lists and campaign processes. | Drupal → Martini → Mailchimp | Martini can validate subscription state and consent, map Drupal user or submission data to Mailchimp fields, and prevent duplicates using stable email and source identifiers. |
| Elasticsearch | Index Drupal content for search, faceting, filtering, and relevance-based discovery. | Drupal → Martini → Elasticsearch | Martini can process changed Drupal Nodes, Taxonomy terms, and Media relationships, build Elasticsearch documents, and handle partial failures without replaying successful items. |
How to build a Drupal integration in Martini
Objective
Establish the Drupal endpoint, enabled modules, exposed resources, environment URLs, and authentication method before building mappings.
Instructions in Martini
- Confirm whether RESTful Web Services, JSON:API, GraphQL, or callback mechanisms are enabled
- Configure the Drupal base URL and resource paths as environment-specific values
- Store Basic Authentication credentials or OAuth 2.0 tokens in Martini secrets
- Verify Drupal roles and permissions for each resource and operation
Objective
Select an event-driven, API-triggered, or scheduled workflow based on the capabilities of the Drupal installation.
Instructions in Martini
- Use a callback only after the event types and delivery contract are confirmed
- Use a Martini API when Drupal is configured to call an external endpoint
- Use a scheduler for polling JSON:API or REST resources
- Define a checkpoint or changed-time strategy for incremental synchronization
Objective
Read Drupal resources safely, including collection pagination, relationships, revisions, and file references.
Instructions in Martini
- Request only the fields and relationships required by the target
- Follow JSON:API pagination links rather than assuming one response contains all items
- Handle missing, inaccessible, unpublished, translated, or revised resources explicitly
- Retrieve Media and File content separately when the Drupal representation requires it
Objective
Coordinate Drupal calls, transformations, target writes, acknowledgements, and state updates in a maintainable Martini workflow.
Instructions in Martini
- Separate source retrieval, transformation, target delivery, and checkpoint updates
- Use conditional routing for content status, consent, file privacy, or object ownership
- Use bounded concurrency for production Drupal sites
- Persist correlation identifiers and processing outcomes
Objective
Transform Drupal entities and relationships into a canonical model or target application schema.
Instructions in Martini
- Map bundle-specific fields rather than assuming all Nodes share one schema
- Use stable UUIDs and explicit entity types as integration identifiers
- Normalize dates, email addresses, multilingual fields, and multi-value relationships
- Distinguish Media metadata, File metadata, and binary content
Objective
Enforce publication, moderation, permission, consent, and validation policies before downstream writes.
Instructions in Martini
- Decide whether drafts, published content, revisions, or translations are synchronized
- Validate required fields before calling the target system
- Exclude private files or restricted content unless the target policy permits transfer
- Treat permission and validation failures as non-transient exceptions
Common Drupal data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Content entities / Nodes | Articles, Basic Pages, and custom content types used for editorial publishing and structured content delivery. | Search platforms, CDNs, Salesforce, HubSpot, Shopify, SAP S/4HANA, and data stores | Martini retrieves configured Node resources through JSON:API or REST, maps bundles and fields, resolves relationships, and applies publication, revision, and translation rules. |
| Users | Drupal accounts, profiles, roles, permissions, and account metadata. | Salesforce, HubSpot, Mailchimp, identity platforms, and customer applications | Martini synchronizes permitted user fields, applies consent and privacy rules, and avoids treating email as the sole identity key. |
| Taxonomy terms | Controlled vocabulary values used to classify and categorize Drupal content. | Search indexes, commerce platforms, CDNs, and downstream content stores | Martini maps term UUIDs, names, vocabularies, and relationships while handling missing or inaccessible references. |
| Media | Reusable images, documents, videos, and remote media associated with content. | Elasticsearch, Shopify, DAMs, CDNs, collaboration platforms, and content delivery services | Martini separates Media metadata from referenced File data and transfers only the binary or access information permitted by Drupal. |
| Files | Managed file metadata and binary assets associated with Media or other entities. | DAMs, object storage, CDNs, document repositories, and collaboration platforms | Martini can retrieve authenticated metadata or binary content where configured, with explicit treatment for private files and failed transfers. |
| Comments | User-submitted comments associated with content entities. | Moderation tools, Salesforce, Jira, analytics stores, and notification services | Martini can synchronize permitted comments, apply moderation and privacy rules, and prevent duplicate downstream submissions using stable identifiers. |
Authentication and security considerations
Configurable authentication
Drupal authentication depends on enabled modules and site configuration. Common options include session authentication, Basic Authentication through the core module, and OAuth 2.0 through contributed modules such as Simple OAuth.
Permissions and transport security
Drupal roles and permissions control access to resources and operations. Authenticated API traffic should use HTTPS, and browser or session-based state-changing requests may require CSRF protection.
Martini configuration
- Store Drupal credentials, OAuth clients, tokens, and base URLs in secure environment configuration.
- Use least-privilege Drupal accounts for each integration workflow.
- Confirm permissions for unpublished content, revisions, relationships, Media, and private Files.
- Validate callback authentication or signing when a Drupal installation sends webhook-style notifications.
Operational considerations for Drupal integrations
Pagination and synchronization state
JSON:API collections are commonly paginated. Martini workflows should follow pagination links, persist checkpoints, and use changed timestamps, revisions, or UUIDs for incremental synchronization.
Schema and content-model changes
Drupal fields, bundles, modules, translations, revisions, moderation states, and relationship structures can change independently of the platform version. Review mappings when fields or entity configurations change.
Load and retry control
Drupal has no single universal rate limit. Reverse proxies, web application firewalls, hosting limits, PHP capacity, modules, and databases may constrain traffic. Use bounded concurrency, backoff, and batch sizes, and retry temporary failures without repeating validation or permission errors.
Idempotency and testing
Use entity, Media, and File UUIDs as stable keys. Test private files, relationship changes, multilingual content, revision conflicts, unpublished resources, schema changes, and duplicate delivery in a representative environment before production rollout.
Why use Martini instead of scripts or point-to-point integrations?
Centralized orchestration
Martini provides a maintainable workflow layer between Drupal and downstream applications. It can consume REST, JSON:API, and confirmed GraphQL endpoints, receive configured callbacks, expose APIs, and coordinate multi-step delivery.
Reusable transformations
Mappings, validation, business rules, relationship handling, and file processing can be implemented consistently rather than duplicated across point-to-point scripts.
Operational control
Martini supports scheduled and event-driven workflows, checkpoints, controlled concurrency, error routing, retries, logging, and environment-specific secrets. This helps teams manage Drupal schema changes and integration failures without embedding all behavior in custom Drupal code.
Frequently asked questions
Drupal can integrate through its core RESTful Web Services and JSON:API modules, which expose configured entities such as Nodes, Users, Taxonomy terms, Media, Files, and Comments. GraphQL is available through a contributed module, while webhook-style callbacks require contributed modules or custom Drupal code. Scheduled API polling is a practical fallback where events are unavailable.
Yes. Martini can consume Drupal REST and JSON:API endpoints, consume a configured GraphQL endpoint, receive confirmed Drupal webhook-style callbacks, expose an API for Drupal to call, and orchestrate synchronization workflows using the authentication and permissions configured on the Drupal site.
No. A dedicated Drupal connector is not required. Martini can integrate using Drupal’s native REST and JSON:API interfaces, a configured GraphQL endpoint, site-specific callbacks, and supported authentication methods.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Drupal. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Drupal hosting, contributed modules, infrastructure, or other third-party services.
JSON:API is generally the preferred Drupal-native interface for structured entity synchronization because it provides consistent resource representations, relationships, filtering, and pagination. RESTful Web Services is appropriate for configured resources and operations that JSON:API does not expose. GraphQL can be used when the contributed module and site-specific schema are confirmed.
Drupal core does not provide a universal outbound webhook facility for all entity changes. A contributed module, custom event subscriber, queue worker, or application implementation may send callbacks for selected events. Martini can receive those callbacks after their payload, authentication, signing, and retry behavior have been verified; otherwise it can poll Drupal APIs on a schedule.
Martini workflows can read filtered and paginated Drupal resources, follow relationships, and map bundle-specific fields into a canonical or target model. Synchronization can use changed timestamps, revisions, UUIDs, or a maintained checkpoint. Explicit rules should define treatment of translations, drafts, moderation states, private files, and unpublished content.
Martini can distinguish authentication, permission, validation, missing-resource, revision, rate-limit, and temporary server errors. Transient failures can be retried with backoff, while non-transient failures can be routed for review. Stable Drupal entity, Media, and File UUIDs support idempotent processing and duplicate prevention.
Related Martini documentation
Workflows
Connect Drupal to your enterprise systems
Use Martini to build reliable Drupal integrations with APIs, workflows, mappings, authentication, and operational controls tailored to your Drupal content model.