Your integration reports an authentication error, but WordPress still lets you sign in. You generate another application password, paste it into the connector, and get the same response. Before changing a user role or disabling a security plugin, establish which part of the request is failing.
When WordPress application passwords are not working, separate three questions: did the request reach the intended WordPress site, did WordPress recognise the intended user, and does that user have permission for this operation? A successful browser login answers none of those questions for an external API client.
Documentation reviewed on October 20, 2026. The diagnostic sequence and worksheet below are proposed implementation practices, not results from a client project or a live test of your website.
The quickest useful test
Use the correct HTTPS site address and an application password belonging to the intended WordPress user. Test the read-only /wp-json/wp/v2/users/me endpoint from a clean API client. Check the returned identity, not just the HTTP status. If that works, investigate the failing endpoint's permissions and the original client's request. If it fails, record the response and check credentials, feature availability and the server's handling of authentication.
This guide concerns external clients using WordPress application passwords. It does not replace the login instructions for WordPress.com, a connector's OAuth flow or WooCommerce REST API consumer keys. Start with your integration's documented authentication method.
Confirm what credential the client expects
An application password is a separate, revocable credential associated with a WordPress user. It is for programmatic access, not signing into wp-admin. In a Basic Authentication client, the username is the WordPress login and the password is the generated application password. The credential's descriptive label is not the username.
The WordPress application-password handbook explains creation, revocation and HTTPS requirements. Grouping spaces in the generated password are accepted by WordPress; do not assume removing spaces will fix every error. Check for accidental quotation marks or an incomplete paste instead.
Use a separate credential for each integration. Give its user only the capabilities the workflow needs. The name you assign to a credential does not restrict it to a particular endpoint. Treat it as a secret, not as a harmless API identifier.
Establish a read-only baseline
Run the following only against a site you own or are authorised to test. Replace the example domain and login with the intended destination and user. The command is for a local interactive terminal with curl installed; it is not an instruction to paste secrets into a chat or an online testing website.
curl --silent --show-error --include --user "YOUR_WORDPRESS_LOGIN" "https://example.com/wp-json/wp/v2/users/me"Enter the application password at curl's password prompt. Supplying only the username makes curl prompt for the password, keeping the secret out of the command itself. Do not add a colon after the username, because that specifies an empty password rather than requesting the prompt. Use curl.exe if your Windows shell maps curl to a different command.
The example deliberately does not follow redirects or disable certificate verification. If the response redirects, verify the destination before entering credentials in a new request. Use the canonical HTTPS address and the correct WordPress installation path. Do not send credentials to an unfamiliar host or solve a certificate error with an insecure flag.
Expect a JSON user response on a successful standard WordPress request. Confirm that the returned user ID and identity match the account intended for the integration. Keep that response private: it may contain information that should not be attached to a public support thread.
| Observed result | Working interpretation | Next check |
|---|---|---|
| 200 with the expected user JSON | This client authenticated for this request. | Compare the original client's request, then check the target endpoint. |
| 200 with a login page or other HTML | The HTTP status alone does not prove API authentication. | Check the URL, redirects and response content type. |
| 401 or a WordPress authentication error | The intended identity has not been established. | Check the credential, availability rules and header delivery. |
| 403 or an access-denied page | A permission check or another protective layer may have denied access. | Identify who generated the response before changing roles. |
| 404 or a routing error | The request may not have reached the expected endpoint. | Check installation path, REST routing and the exact response body. |
| TLS or connection failure | Authentication has not yet been meaningfully tested. | Resolve the connection or certificate issue with the host. |
WordPress's authorization-error helper distinguishes unauthenticated and logged-in users with 401 and 403. That does not mean every 403 on the internet proves WordPress accepted your password. A firewall, reverse proxy or plugin can produce its own response before that code runs.
When the application-password feature is missing
If there is no Application Passwords section in the relevant user's profile, investigate feature availability before repeatedly changing credentials. Check HTTPS and ask the site maintainer whether a security policy or custom filter disables application passwords globally or for that user. A restriction may be deliberate.
Do not install a second authentication plugin simply because a field is absent. Do not force application passwords on over an unencrypted production connection. Ask whether this integration is permitted and which supported authentication method the site is intended to use.
For conflicts that require changing plugins or code, reproduce the problem in an isolated environment first. Our WordPress staging checklist covers separating testing from live orders and notifications. Give the test environment its own credentials rather than reusing production secrets.
When credentials seem correct but identity still fails
Start with the simple mismatch: the application password must belong to the same user supplied in the request, on the same installation. A credential revoked on that site will not work. A working browser session is not evidence that the saved integration credential is correct.
Then compare the direct test with the integration. Are both using the same hostname, path and authentication method? Does the integration follow a redirect? Is it sending Basic Authentication, or incorrectly putting the application password into a Bearer token field? Is there a second authentication layer in front of WordPress?
WordPress documents server handling of Authorization headers as a possible cause of failure. Ask the host to confirm that the header reaches PHP through the actual proxy and web-server chain. Confirmation should record presence and handling, not expose the header value in logs.
Do not paste a collection of Apache and Nginx snippets into production. The relevant configuration depends on the server and PHP integration. Give the host a timestamp, request path, response code and request identifier, then ask for a scoped fix with a rollback plan. A missing header is a hypothesis until someone verifies it.
HTTP Basic Authentication protecting a staging site is another complication: that outer login and WordPress application-password authentication may compete for the same Authorization header. The WooCommerce mobile-app troubleshooting guide explicitly documents its limitation with sites behind HTTP Basic Authentication. Do not remove staging protection blindly; have the host and integration maintainer agree on a protected, supported test arrangement.
When identity works but the operation fails
A successful identity check does not grant permission to publish a post, upload media or change another user's records. Record the exact route, HTTP method and intended operation. Then check the endpoint's documented capabilities and any object-specific restrictions.
For a custom route, review its permission callback with the developer. Authentication identifies the caller; the callback decides whether the request is allowed. Replacing that check with an unconditional success response is not a repair for a private endpoint.
For example, suppose an integration can retrieve its user identity but cannot modify a particular record. Reissuing the password is unlikely to resolve a route-specific permission rule. The useful evidence is which operation fails, which user was recognised and what capability or ownership check the endpoint requires. This is an illustrative scenario, not a report from an ICT customer.
Avoid giving the integration Administrator access merely to make the error disappear. Agree on the minimum required permissions and test both an allowed operation and an operation that should remain forbidden in staging. A fix is incomplete if it makes unauthorised requests succeed.
If the connection is part of a lead workflow, the WordPress-to-CRM integration guide covers the next layer: field mapping, duplicate handling and delivery checks. Not every CRM connector uses application passwords; authentication and workflow reliability are separate concerns.
Build a support handoff without leaking the password
A useful support ticket lets another person reproduce the relevant comparison without asking you to disclose credentials. Fill in one row for the direct identity check and another for the original failing request.
| Record | Include | Leave out |
|---|---|---|
| Destination | Environment, hostname and path | Secret query parameters |
| Request | Timestamp with timezone, method, client and request ID if available | Authorization header, cookies and password |
| Response | Status, content type and redacted error code/message | Personal records or complete user objects |
| Identity | Whether the expected user was confirmed; share account details privately only if needed | Unnecessary personal account information |
| Comparison | Direct test versus integration; what changed between them | Unrelated logs or customer payloads |
| Decision | Owner, proposed change, rollback and retest result | Unapproved blanket security exemptions |
Stop repeated retries while investigating a persistent rejection. After an authorised change, repeat the same baseline and then test the intended workflow in staging. If credentials were exposed during troubleshooting, revoke the affected credential and replace it through your normal secure process. Confirm the integration uses the replacement before considering recovery complete.
Need help separating a connector problem from a custom endpoint problem? Explore ICT's WordPress plugin development services. A useful starting brief is the redacted worksheet, the required operation and the integrations involved—not a password in a contact form.
Frequently asked questions
Can I use an application password to sign into WordPress?
No. It is intended for API clients and scripts. Use the site's normal interactive login method for the dashboard.
Does a 403 mean my password is correct?
Not by itself. WordPress may return 403 for a logged-in user without permission, but another layer can also reject the request. Confirm the response source and test the expected identity before drawing that conclusion.
Why does the direct test work but my integration fail?
Compare destination, method, authentication scheme, redirects and the operation being attempted. The direct request proves only that its particular path and identity check worked. It does not prove the integration sends the same request.
Should I add a WordPress nonce to an external client?
Do not mix authentication methods without a reason. WordPress's authentication handbook describes cookies and nonces for requests made within a logged-in WordPress context, and application passwords for supported external clients.
Should I disable security plugins to find the problem?
Start with evidence and documented settings. If a conflict test is necessary, arrange a controlled staging test with the site owner. Avoid blanket production changes that expose the site or obscure which setting caused the failure.
Fix the failed layer, then verify the workflow
The goal is not merely to replace an error with a 200 response. Confirm the right user, the permitted operation and the expected business result, while keeping disallowed actions blocked. That gives you a defensible fix and a record the next maintainer can use.
For a scoped integration review, send ICT your requirements and redacted diagnostic summary. Keep passwords, authentication headers and customer data out of the enquiry.
