WordPress API credentials unexpected error 'Forbidden'

Questions
,
1

“Couldn’t connect with these settings
Forbidden - perhaps check your credentials?”

Describe the problem/error/question

I am stuck on connecting the WordPress API credentials, but I don’t think I missed out on any steps. The username is the username of the account on the WordPress environment, the password is the application password to the same account from within the WordPress environment, and the account is connected to a Wordpress.com account with 2FA enabled, connected through the JetPack plugin. The WordPress URL is without a trailing slash and the toggle of Ignore SSL Issues has no effect on the error. The account in the WordPress environment has the admin role as well, so that shouldn’t be an issue either. Does anyone know what I could be missing here?

Information on your n8n setup

  • n8n version: [email protected]
  • Database (default: SQLite): SQLite
  • Running n8n via (Docker, npm, n8n cloud, desktop app): Web app
  • Operating system: iMac - Google Chrome V146.0.7680.80
2

Hi @Sun_NB Welcome!
Try adding these lines into your .htaccess file:

RewriteCond %{HTTP:Authorization} ^(.*)
RewriteRule ^(.*) - [E=HTTP_AUTHORIZATION:%1]
SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1

I guess this is related to this issue here:

3

Hi @Anshul_Namdev , thanks for the quick reply. I received those lines from the documentation AI chatbot as well and implemented it in the following way:

<IfModule mod_rewrite.c> 
RewriteEngine On 
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] 
RewriteBase / 
RewriteRule ^index\.php$ - [L] 
RewriteCond %{REQUEST_FILENAME} !-f 
RewriteCond %{REQUEST_FILENAME} !-d 
RewriteRule . /index.php [L] 
RewriteCond %{HTTP:Authorization} ^(.*) 
RewriteRule ^(.*) - [E=HTTP_AUTHORIZATION:%1] 
SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1 
</IfModule>

This didn’t fix the issue, sadly. Though maybe I did it wrong, since I’m not very familiar with the way to do things in a htaccess file. Could it be a wrong way of adding it of mine, or does it look about right to you?

4

hey @Sun_NB — if your host uses Nginx, those .htaccess rules won’t have any effect (they’re Apache-only), so worth checking that first. also, with Jetpack active, the Application Password needs to be created in your WordPress admin dashboard (Users > Profile > Application Passwords), not in WordPress.com — if you created it on the WordPress.com side it won’t work for the self-hosted REST API. which hosting provider are you on?

5

Hi @Benjamin_Behrens,

I changed the password in my n8n credentials to the application password from the WordPress environment, but this didn’t seem to do the trick. This leads me to think it might be due to Nginx as you mentioned, but I’m not too familiar with the server side and haven’t figured out how to host using Apache yet. The PHP version 8.4 is being executed as Apache, but other than that I haven’t found much that leads me to think it could be the ‘switch‘ from Nginx to Apache.

My hosting provider is Plesk.

Does this help for insight on the situation? Please feel free to let me know if you need any more info.

Thanks in advance!

6

Hey @Sun_NB — Plesk typically runs Nginx as a reverse proxy in front of Apache, so the Authorization header can get stripped before your .htaccess rules even have a chance to process it. Worth checking under Websites & Domains → Apache & nginx Settings in your Plesk panel — if Nginx mode is active, you’d want to add proxy_set_header Authorization $http_authorization; in the additional Nginx directives field there.

Also, just to confirm: the Application Password you’re using was generated in the WordPress admin dashboard at Users → Profile → scroll down to “Application Passwords” — not the general WordPress.com account password? With Jetpack connected it’s an easy mix-up, and the two are separate credentials.

7

Hi @Benjamin_Behrens, thanks for the quick reply. I checked and saw that ‘Websites & Domains‘ is only visible on the Power User-display. When switching to this view, I only see the domains that are connected to the webspace selected top right. ‘Apache & nginx Settings‘ isn’t visible for me, and I couldn’t find a way to navigate to it using the Plesk documentation either. I’ve found Apache with nginx | Plesk Obsidian documentation, but seem to lack access to ‘Server management‘.

Could there be a step I’m missing to navigate to ‘Apache & nginx Settings‘ from the ‘Websites & Domains‘ as you mentioned?

Also the Application Password was generated in the website domain’s back-end, yes. This time I didn’t take the password from Wordpress.com, but from the website domain in the directory you mentioned.
Thanks for confirming!

8

hey @Sun_NB — if the server management options aren’t accessible on your plan, the easiest path is to contact your hosting support directly and ask them to add proxy_set_header Authorization $http_authorization; to the Nginx config for your domain. most hosts can do that as a quick config change.

alternatively, there’s a PHP-level workaround that doesn’t require server access — add this near the top of your wp-config.php (before the wp-settings.php include):

if (!isset($_SERVER['HTTP_AUTHORIZATION']) && isset($_SERVER['REDIRECT_HTTP_AUTHORIZATION'])) {
    $_SERVER['HTTP_AUTHORIZATION'] = $_SERVER['REDIRECT_HTTP_AUTHORIZATION'];
}

this catches cases where Nginx passes the Authorization header under a different key after proxying. worth trying before going back and forth with support.

9

Hi @Benjamin_Behrens, I’ve added the snippet to the wp-config.php file at the very top, right below the opening tag. Then tried to verify the credential again after a refresh, but sadly with the same error result.

I will contact our hosting support and see if they can add the configuration settings for us, thanks for providing the information. When this is done, I’ll share another update to let you know if it worked. Thanks!

10

hey @Sun_NB — makes sense, the PHP snippet only helps if the Authorization header is actually reaching the PHP layer, which in your case it sounds like it isn’t. when you reach out to hosting support, just ask them to add proxy_set_header Authorization $http_authorization; to the Nginx vhost config for your domain — that exact phrasing should make the ticket easy to handle on their end. looking forward to hearing if it sorts it out!

11

Hi @Benjamin_Behrens,
The snippet has been added by the hosting party, but the same error keeps showing up. I’ve cleared cache and tried again, deactivated all plugins and tried again to see if there was anything blocking, but these didn’t fix the issue.

Are there any niche causes that could end up in the ‘Forbidden - perhaps check your credentials?‘ error?

12

hey @Sun_NB — still getting Forbidden after the host added the directive is unexpected. a few things to check next:

  • ask your host to confirm Nginx was actually reloaded after the config change (not just saved) — it only takes effect after a reload (systemctl reload nginx or similar)
  • with Jetpack active, try temporarily deactivating it and testing the connection again — it has its own authentication layer that can sometimes conflict with Application Password auth on the REST API path
  • visit https://[yoursite]/wp-json/ in your browser — if you get an error instead of a JSON response, the REST API itself may be restricted at the WordPress level (some security plugins like Wordfence disable REST API access by default)

if all of that checks out, one more thing: in your n8n credentials, the password field should contain the Application Password exactly as WordPress generated it (with spaces, as shown) — just worth confirming it wasn’t accidentally modified.

13

Hi @Benjamin_Behrens, here’s a process update; I’m waiting for my host to respond, but I’ve tested the other suggestions.

-Jetpack
I deactivated the plugin and reactivated it, then reconnected the WordPress.com account. After this I went and hard reloaded the credentials page on n8n but the same error persisted.

-JSON test
I added the slug and it showed me a JSON response, so this shouldn’t be an issue either.

-Application password
To be certain I’ve generated another application password, copied it, reloaded the n8n credential page and pasted it without changing it one bit and retried. The forbidden error still appeared.

I’ll redo these when I hear back from my host just to be sure.