Last updated: September 10, 2026
WPWriter (wpwriter.com) and WP Agent (getwpagent.com) connect to a customer's WordPress site only after the site owner has authorized the connection. The exceptions are the unauthenticated checks listed below: the public connection diagnostic, and the automated follow-up checks that repeat part of it after a failed connection attempt. Nearly all of that traffic is WordPress REST API calls; the optional file and database modes below are the exceptions. Everything leaves from one fixed address. Hosting providers and firewall administrators can allow-list it with the details below.
164.90.235.32
Every path below is relative to the WordPress installation address the site owner connected. For a site installed in a subdirectory, such as https://example.com/blog, read /wp-json/* as /blog/wp-json/* and /?rest_route=* as /blog/?rest_route=*.
| Products | WPWriter (wpwriter.com) and WP Agent (getwpagent.com) |
|---|---|
| User-Agent | WPWriter/1.0 (+https://www.wpwriter.com; support@wpwriter.com) |
| Authenticated REST calls | Requests to the site's own address, over HTTPS when the site uses it (a site connected with an http:// address is reached over HTTP). Calls are signed with the site owner's Application Password or the connector plugin's token. Paths: /wp-json/wp/v2/*, /wp-json/wp-writer/v1/* and /wp-json/wp-manager/v1/* (WPWriter connector plugin, current and legacy namespaces), /wp-json/wp-agent/v1/* (WP Agent connector plugin), /wp-json/wc/v3/* on WooCommerce sites. WPWriter Application Password connections fall back to the /?rest_route=/... form when /wp-json/ answers with HTML or a non-WordPress 404, and so do the WPWriter connector plugin's discovery and pairing steps; established connector-plugin traffic uses /wp-json/ only. WP Agent's authenticated calls use /wp-json/ only; its connection check sends one unauthenticated GET /?rest_route=/ when /wp-json/ fails, to tell plain permalinks from a blocked API. Methods: GET, POST, PUT, PATCH, DELETE. The list names the namespaces the built-in tools use; individual routes under them vary with the site's plugins. WP Agent's raw REST tools can also reach any other namespace the site exposes (a plugin's own API, for example), with the same credential and subject to a deny-list: the batch endpoint and sensitive write routes are refused before anything is sent. |
| Unauthenticated discovery | GET /wp-json/ (the REST index) when a site is first connected, to check that the REST API is reachable; WPWriter may also probe a few /wp-json/wp/v2/* routes at that point |
| Public connection diagnostic | When a person submits a site address to the connection checker on wpwriter.com (anonymous, rate-limited per visitor), this address sends that site a short unauthenticated probe sequence: GET /wp-json/, GET /?rest_route=/, GET /wp-json/wp-manager/v1/ping (and its /?rest_route= form), POST /wp-json/wp-manager/v1/pair with a dummy code (and its /?rest_route= form), GET /wp-json/wp/v2/users/me. Nothing is written; the plugin rejects the dummy code |
| Automated follow-up checks | After a failed connection attempt, and again before a follow-up email about it, the service repeats the public diagnostic (or just its GET /wp-json/ check) against the site the person tried to connect, to confirm the problem still exists before writing to them. A few requests per site, in the days after the attempt |
| Public page checks | GET of a post's public URL (the site's home page for a draft) when the post is opened in WPWriter's editor or after it is published, to read its SEO metadata. Broken-link scans send HEAD requests (and sometimes a small ranged GET) to the links inside a post, including the site's own pages. Same User-Agent |
| Authorization | Application Password connections (WP Agent, and WPWriter's one-step connect): the one-time approval happens on /wp-admin/authorize-application.php, opened by the site owner in their own browser, not from this address; the first authenticated checks follow from this address once approved. WPWriter connector-plugin connections: one successful server-side POST from this address to /wp-json/wp-manager/v1/pair (retried once as /?rest_route=/wp-manager/v1/pair if the first attempt returns HTML or a non-WordPress 404), carrying the pairing code the site owner generated in their WordPress admin |
| Media fetches | GET of image files from the site (its /wp-content/uploads/* URLs) when a person browses the site's media library in WPWriter or reuses one of its images; GET of an image from another public host when a person asks to add an image by URL. Same User-Agent |
| Optional FTP | WPWriter customers can enable file deployment to their site over FTP; the service uses FTP or explicit FTPS according to its configuration. The control connection goes from this address to the host and port the customer entered; transfers use passive mode, so the data connections go to the ports that FTP server assigns |
| Optional direct database (legacy) | WPWriter still supports an advanced mode that connects straight to the site's MySQL database using the host, port and credentials the customer entered. Those connections leave from this address to that host and port only |
| When | While a site owner works with the assistant; on the schedule the owner sets for automatic publishing (WPWriter autoblogging); and occasionally in the background while the owner is not present: an authenticated read of a site's recent posts shortly after it is connected (to choose which welcome tips to send), an authenticated read of a connected site's recent posts and categories (GET /wp-json/wp/v2/posts and /categories) to prepare a post-idea email, and the follow-up checks above after a failed connection attempt |
| Typical volume | About 12 requests per site per hour during a working session; a handful per scheduled run or background check |
An allow-list by address is broader than a path-scoped exception. Where your firewall supports it, the narrowest rule that works is: allow 164.90.235.32 for requests to /wp-json/* and /?rest_route=* under the WordPress installation path (/blog/wp-json/* and /blog/?rest_route=* for a site installed at /blog). That covers the REST traffic; the page checks and link scans above are ordinary public page requests that every site already serves.
Two commands on the server, from the Imunify360 vendor's own note:
imunify360-agent ip-list local add --purpose white 164.90.235.32 imunify360-agent create-rbl-whitelist
The first whitelists the address; the second regenerates the WAF RBL whitelist so the change also covers WebShield's bot-protection rules. Reference: CloudLinux article 4418879896850. In the Imunify360 panel the same setting is Firewall → White List → Add IP.
Allow 164.90.235.32 for requests to /wp-json/* and /?rest_route=* under the WordPress installation path (for example /blog/wp-json/* on a subdirectory install). Cloudflare: prefer a WAF custom rule with action "Skip" scoped to this IP and those paths; an IP Access Rule set to Allow also works, but it bypasses every WAF rule, rate limit and security log for the address. Wordfence: Firewall → Allowlisted IPs. Sucuri: Firewall → Access Control → Whitelist IP.
Write to support@wpwriter.com. Abuse reports about this address are read the same day.