Sign Up
Documentation

Connect WordPress

Push AI Coworker articles directly to WordPress via the REST API and Application Passwords.

PingAura connects to WordPress through the official WP REST API and an Application Password. Once connected, the AI Coworker can publish or update articles in your WordPress site without leaving the chat.

Before you begin

  • A self-hosted or WordPress.com Business+ site with the REST API enabled at https://your-site.com/wp-json/wp/v2.
  • A user account on that site with edit_posts capability (Editor or higher recommended for publishing).
  • The ability to create an Application Password for that user (Users → Profile → Application Passwords).

Connect

  1. Go to Integrations in PingAura and click Connect on the WordPress card.
  2. Enter your Site URL — the root of your WordPress install (e.g., https://example.com or https://blog.example.com). Don't include /wp-json or any sub-path.
  3. Enter your WordPress username (the user that owns the App Password).
  4. Generate an Application Password in WordPress (see below) and paste the value (spaces are fine — WordPress accepts the hyphenated display form).
  5. Click Connect. PingAura will validate the credentials and the REST API before saving.

Application Password

The exact location depends on whether your site is self-hosted or hosted on WordPress.com.

Self-hosted WordPress (wordpress.org install)

  1. Sign in to your WordPress admin (https://your-site.com/wp-admin).
  2. Go to Users → Profile (or Users → Your Profile).
  3. Scroll to the Application Passwords section near the bottom of the page.
  4. Enter a name (e.g., PingAura) and click Add New Application Password.
  5. Copy the 24-character password shown (it's only visible once). Paste it into PingAura.

If you don't see the section, your host or a plugin has likely disabled Application Passwords. Make sure WordPress is on version 5.6+ and the site is on HTTPS. See Application Passwords section missing below for the fix.

Application Passwords section missing

If the Application Passwords section doesn't appear at the bottom of your profile page despite WP 5.6+ and HTTPS, something is filtering it off. Common culprits:

  • A bundled "tools" or "security" plugin from your managed host (Hostinger Tools, SiteGround Optimizer, etc.) that disables the feature by default.
  • A standalone security plugin (Wordfence, Solid Security, All In One WP Security) with the App Password toggle turned off.
  • The WP_ENVIRONMENT_TYPE constant in wp-config.php set to 'local', 'development', or 'staging' — WordPress auto-disables App Passwords outside production.
  • A DISABLE_WP_APPLICATION_PASSWORDS constant defined in wp-config.php.

Two ways to force-enable:

Option A — Force-enable via a small mu-plugin (recommended, host-agnostic)

A "must-use plugin" auto-loads on every request without showing up in the plugin list. This works regardless of what is disabling the feature, and survives plugin/theme updates.

  1. Open your host's file manager (or SFTP into the site).

  2. Navigate to wp-content/mu-plugins/. If the mu-plugins folder doesn't exist, create it.

  3. Inside mu-plugins, create a new file named force-app-passwords.php.

  4. Paste exactly this and save:

    <?php
add_filter( 'wp_is_application_passwords_available', '__return_true', 999999 );
add_filter( 'wp_is_application_passwords_available_for_user', '__return_true', 999999 );

  5. Hard-refresh https://your-site.com/wp-admin/profile.php (Cmd/Ctrl+Shift+R). The Application Passwords section now appears at the bottom.

The high priority (999999) makes our filter run after the blocking filter, so ours wins. The second filter handles the per-user variant some plugins use instead of the global one.

Do not add add_filter() directly to wp-config.php — that file runs before WordPress core loads, so the function doesn't exist yet and you'll get an HTTP 500. Always use the mu-plugin approach.

Option B — Disable whatever is blocking it

If you'd rather not add a file:

  1. WP admin → Plugins → Installed Plugins.
  2. Look for security or host-bundled "tools" plugins (often named after the host, e.g. anything with the host's brand name in the title).
  3. Click Deactivate under suspect plugins one at a time, refreshing profile.php between each, until the section reappears.
  4. Once you identify the culprit, check that plugin's settings for an "Application Passwords" toggle — you can usually re-enable it without disabling the whole plugin.

You can reactivate any plugin you deactivated for the test. The point is to find the one that's filtering App Passwords off.

WordPress.com hosted sites

WordPress.com only exposes the standard WP REST API on Business plan and above. On Free/Personal/Premium plans the REST API at your-site.wordpress.com/wp-json/wp/v2 is not publicly available, so the integration cannot push articles regardless of which password you use.

If you're on Business+:

  1. Go to https://wordpress.com/me/security/ (account-level, not per-site).
  2. Scroll to Application Passwords at the bottom.
  3. Click Add New Application Password, name it PingAura, and click Generate.
  4. Copy the password and paste it into PingAura.

Quick sanity check before connecting — open in a browser:

https://your-site.wordpress.com/wp-json/wp/v2/posts
  • See JSON → REST API works, the integration will connect.
  • See HTML / login redirect → your plan doesn't expose it, upgrade to Business or self-host.

What we test at connect time

When you click Connect, PingAura issues an authenticated GET https://your-site.com/wp-json/wp/v2/. The connection is rejected if any of the following is true:

  • The request times out (>15 s) — your site is unreachable.
  • The response is 401/403 — the username or App Password is wrong.
  • The response is 2xx but the body is HTML — your URL points at a marketing/landing page, or the REST API is being intercepted by a security plugin / WAF.
  • The response is 200 but not valid JSON — something else is sitting in front of the API.

The error message in the dialog tells you which one fired. Each one points at a specific fix below.

Troubleshooting

"Site URL returned an HTML page instead of the WP REST API"

Your site URL responded 200 OK but with HTML, not JSON. The most common causes, in order:

  1. You entered the wrong URL. It needs to be the WordPress install itself, not a marketing site. Visit https://<your-url>/wp-json/wp/v2/ in a private browser window — if you don't see JSON, the URL is wrong. Common mistakes:

    • example.com when WordPress lives at blog.example.com.
    • A Webflow / Framer / Wix site that isn't WordPress at all.
    • A landing page that proxies /wp-json to a 404 page rendered as HTML.

  2. A security plugin is blocking the REST API. Wordfence, iThemes Security, "Disable REST API", and similar plugins often serve an HTML challenge or block page for /wp-json/* requests instead of letting them through. Either:

    • Whitelist the REST API in the plugin settings.
    • Whitelist PingAura's egress IPs (contact support for the current list).
    • Or temporarily disable the plugin to confirm it's the cause.

  3. A host-level WAF or CDN is intercepting the request. Some hosts (notably free tiers like InfinityFree, 000webhost, and similar) serve an anti-bot HTML interstitial to non-browser traffic. The WP REST API never gets a chance to respond. The fix is to host on a provider that doesn't gate API requests — most paid WordPress hosts (Kinsta, WP Engine, Cloudways, SiteGround, Bluehost, etc.) don't have this problem.

  4. .htaccess rewrite is broken. If you've recently changed permalinks or migrated, the rewrite rules may not be regenerated. Go to Settings → Permalinks in wp-admin and click Save Changes without changing anything — this rewrites .htaccess.

"Authentication failed (401/403)"

  • The username is the WordPress login name, not the display name or the email address.
  • Application Passwords must be generated under Users → Profile → Application Passwords in wp-admin. Regular passwords don't work — WordPress disabled regular-password Basic Auth in 5.6.
  • The Application Password value PingAura expects is the long string with spaces shown right after you create it (e.g., xxxx xxxx xxxx xxxx xxxx xxxx). Paste it exactly as shown.
  • The user must have at least the Editor role to create + publish posts. Contributors can save drafts but not publish.

"Request timed out after 15s"

  • Open https://<your-site>/wp-json/wp/v2/ in your browser. If it loads slowly there too, your host is slow — consider upgrading the host plan or enabling object caching.
  • If your browser is fast but PingAura times out, your host may be rate-limiting non-browser User-Agents. Whitelist PingAura's egress IPs in your firewall.

"WordPress REST API returned status N"

  • 404 — REST API isn't reachable at the URL you provided. Same fixes as the HTML-response case above.
  • 500/502/503/504 — your host is having a moment. Retry in a few minutes.
  • Anything else — the message in the dialog includes the specific status. If it's not in this list, contact support with the exact text.

Publishing an article

Once connected, the AI Coworker shows a "Publish to WordPress" button on every article. Clicking it pushes the article as a draft (or directly publishes, if you choose). PingAura stores the WordPress post ID, so subsequent edits to the same article update the existing post instead of creating duplicates.

Disconnecting

Disconnect from Integrations → WordPress → ⋯ → Disconnect. Your existing WordPress posts are NOT deleted — only the link between PingAura and your site is removed.