Wordpress - Mysql - n8n

Help me Build my Workflow
1

Hi :slightly_smiling_face: I’m quite new to WordPress and n8n, so I’d appreciate some guidance.

I need to build an n8n workflow that checks, based on an email address, whether a user/subscriber exists in our WordPress-based training platform.

Ideally, I’d like to read information that may be visible on the user account/profile, such as:

  • account/email exists,

  • user role/type,

  • free or paid subscription,

  • access to specific courses/trainings.

What is the safest way to do this in n8n?

Would you recommend using the WordPress REST API, or connecting n8n directly to the MySQL/MariaDB database with a read-only user?

I mainly want to avoid accidentally changing or damaging anything in the database. Is it possible to configure WordPress/API access as read-only for this kind of user/subscriber lookup?

1 Like
2

Anna, I’d keep this away from direct MySQL unless there’s a very specific reason. For a training platform, the safer pattern is a tiny WordPress-side read-only lookup that returns only what n8n needs: exists/not found, role or type, subscription state, and course access flags. If your membership/LMS plugin stores access in custom tables or user meta, map that once, then test against a few known emails before the workflow touches production.

I do this as a focused build when teams need the lookup to be safe instead of experimental: read-only WordPress side, n8n request shape, failure handling, and a repeatable test matrix so it can’t update users by accident. If you want that done cleanly, reply here with the LMS/plugin name and I’ll scope the exact path.

2 Likes
3

Hi @Anna5

One extra point I would add is to keep the lookup response small and predictable, then use n8n only for routing. For example, have WordPress return only fields like exists, role, subscription, and course access flags. Then use IF or Switch nodes in n8n based on that response.

I would also handle three cases separately: user found, user not found, and lookup failed. That avoids treating an API/database error as if the user simply does not exist. Test first with a few known emails before connecting it to any production action.

2 Likes
4

Hi @Anna5, great question and smart to think about safety first!

Building on the advice above, I strongly recommend the WordPress REST API approach over direct MySQL. Here’s a concrete setup that works well in n8n:

Use the built-in /wp-json/wp/v2/users endpoint:

In n8n, add an HTTP Request node:

  • Method: GET
  • URL: https://yoursite.com/wp-json/wp/v2/users?search={{ email }}
  • Authentication: Basic Auth with an application password (created under Users > Profile in WP admin)

This returns the user object if found, including their id, name, roles, and registered_date.

For subscription/course access (if you use LMS plugins like LearnDash or MemberPress):

  • LearnDash has its own REST API endpoints
  • MemberPress also has a REST API you can use to check membership status by email

Why avoid direct MySQL:

  • WordPress has its own caching and plugin hooks - bypassing them can return stale data
  • Any plugin (Elementor, WooCommerce, LMS) may store data in serialized formats that are hard to parse raw
  • The REST API enforces proper permissions automatically

What LMS or membership plugin are you using? That’ll help narrow down the exact endpoint to call from n8n.

1 Like
5

Hi @Anna5,
I think the others already did a very good job here.

One small addition I would make is to keep the lookup response small and predictable, then let n8n handle only the routing. That way you can separate
“user found”
“user not found”
“lookup failed” more cleanly.

Very nice answers so far; well done to everyone.

2 Likes
6

Hi, thank you for the suggestion. I tested this endpoint:

/wp-json/wp/v2/users?search=email@example.com

It works when I search by user name/slug, but it does not return the user when I search by email address, even though the user exists.

Was this endpoint meant only as a general example, or should it also search by email when authenticated with Application Password?

For my use case I need to reliably check users by email address and return user/subscription data. Would this require a custom WordPress REST endpoint using something like get_user_by('email', $email)?

1 Like
7

@Anna5 Great catch, and thanks for actually testing it! You’ve identified a real limitation of the WordPress REST API.

The /wp/v2/users?search= parameter in WordPress does not search by email address. By design, WordPress intentionally restricts email-based user lookup via the REST API for privacy and security reasons. Even authenticated requests with an Application Password won’t change that behavior.

Here are your two best options:

Option 1: Query MySQL directly (simplest for your setup)

Since you already have MySQL connected in your n8n workflow, this is actually the cleanest path. You can query the wp_users table directly:

SELECT ID, user_login, user_email, display_name 
FROM wp_users 
WHERE user_email = '{{ $json.email }}'
LIMIT 1;

Then if you need subscription/meta data, query wp_usermeta with the returned ID. This is fast, reliable, and doesn’t need any plugin.

Option 2: Custom WordPress REST endpoint (more proper but more work)

You’d add a small snippet to your theme’s functions.php or a custom plugin that registers a new endpoint like /wp-json/myplugin/v1/user-by-email?email=test@example.com. This is the “proper” API approach but requires touching your WordPress code.

For most n8n automation use cases, Option 1 (direct MySQL query) is simpler and faster to implement, especially since the database connection is already there.

Hope that unblocks you! If you go with the MySQL approach and run into issues with the usermeta query for subscription data, feel free to share the query and I can help fine-tune it. If this solves your problem, feel free to mark it as Solution!

8

I’ve had better luck sticking to the REST API, mostly because WordPress likes to do its own thing under the hood and direct DB access can get quirky fast. If the default endpoints choke on email lookups, a tiny custom endpoint usually does the job. I also toss a rate limit or a small delay in n8n so WordPress doesn’t freak out during bursts.

1 Like