Drupal integration
No native Drupal connector, here is what does work.
Create Drupal nodes through JSON:API with publish state control and Scheduler support.
How it works
SearchHandled writes to your Drupal site through the core JSON:API module, authenticating with Basic Auth or OAuth via simple_oauth. Content arrives as nodes of the content type you choose, with body, summary, taxonomy terms, and image media handled through the proper JSON:API relationships. One thing to know before connecting: JSON:API ships read-only, so your site must explicitly enable write operations, which are off by default.
Drupal's publish model is a status flag, published or unpublished, and we map to it directly: new content defaults to unpublished so it waits in your admin for review, and publishing flips the status on approval. If your site runs the Scheduler module, we set its fields so scheduled publishing happens inside Drupal on Drupal's clock. Because Drupal sites vary enormously (versions, modules, proxies), our connection diagnostics test each endpoint we need individually.
Best forOrganizations on Drupal 9 or 10 with an established content architecture who want nodes created through the front door.
Setup, step by step
- Enable the JSON:API module and allow write operations (accept all JSON:API CRUD operations) in your site configuration.
- Create a dedicated Drupal user with permissions to create and edit the target content type, plus a role that allows API authentication.
- Choose Basic Auth or OAuth (simple_oauth) and provide the credentials in SearchHandled.
- Run the connection diagnostics, which probe each required endpoint and report per-endpoint results in plain language.
- Map the content type and fields, then deliver an unpublished test node for review.
Best practices
Create a dedicated API user with a minimal role
Give the SearchHandled user exactly the node create and edit permissions it needs on the target content type. Drupal's permission grid makes over-granting easy; a minimal role keeps the connection safe and debuggable.
Pick one authentication path and stay on it
Mixing cookie, basic, and OAuth authentication is where Drupal API setups go wrong, because their requirements differ. Choose one method for this connection and configure only that.
Use Scheduler for timed publishing
If you want scheduled posts, install the Scheduler module and we will set its publish-on fields. Scheduling then lives in Drupal, visible to your editors, and fires on cron like the rest of your site.
Retest after major module or version updates
Self-hosted Drupal changes under you: a core upgrade, a new security module, or a proxy change can alter API behavior. Re-run connection diagnostics after significant site updates rather than discovering a break at delivery time.
Known issues
What practitioners actually report, from official docs, issue trackers, and community forums.
403 on POST despite seemingly correct permissions
Node creation returns 403 for non-admin users even when the role looks right, and depending on authentication provider priority the Basic Auth header can be silently ignored, making the same credentials work in one setup and fail in another.
How we handle itOur scripted permission check distinguishes the 403 variants (missing permission, ignored auth header, entity access) and tells you the specific remediation for the one you hit.
drupal.org
CSRF token confusion across auth methods
Cookie-based authentication requires an X-CSRF-Token header while Basic Auth does not, and mixed setups produce inconsistent failures that look random.
How we handle itWe standardize on a single auth path per connection and always send the application/vnd.api+json content type, removing the ambiguity that causes these failures.
drupal.org
Self-hosted variance breaks generic assumptions
Drupal versions, contributed modules, reverse proxies, and hosting stacks differ so much between sites that an integration working on one site can fail on the next for unrelated reasons.
How we handle itOur connection diagnostics test endpoint by endpoint (auth, read, create, media, taxonomy) and report human-readable causes per failure, so setup issues are located rather than guessed at.
drupal.org
Questions teams ask
- Why does my site need configuration changes before connecting?
Because Drupal ships JSON:API read-only by design; write operations are off by default. Enabling them plus creating an API user is a one-time change, and our diagnostics confirm each piece is in place.
- Which Drupal versions are supported?
Any version where JSON:API is in core, which means Drupal 9 and 10 in practice. Because contributed modules and hosting vary so much, the connection diagnostics are the real compatibility test for your specific site.
- Can content be scheduled?
Yes, if your site runs the Scheduler module, which is the standard Drupal answer to scheduling. We set its fields so timed publishing runs inside Drupal. Without Scheduler, content waits as unpublished until approved.
Not connectable yet
Start with the plan, not the connector.
Build a Growth Map from your site to see the work itself. Approved pages can leave through the export or the webhook today, and telling us Drupal matters moves it up the rollout.