How to fix HTTP Errors in Infusionsoft HTTP POST

Web Server responses are divided into groups, 200-299, 300-399, 400-499, 500-599, etc. Each group is a related family of responses, 200 responses are normal, 300 are redirects, 400 are access denied or client errors, 500 are server errors, etc.

If you are receiving a 300 or 400 series error, then the HTTP POST from Infusionsoft is being blocked before Memberium can receive it. These errors are usually easily fixable, and we’ll walk through them below.

If you are receiving a 500 error, then the HTTP POST from Infusionsoft is being received, but something is causing a server crash and it will require some investigation. Contact us at Support with the details of how to reproduce the error.

We’ll go through the common errors below in order, and touch on how to solve them. The most common sources of errors are:

• Security and Anti-Virus Plugins
• .htaccess File Settings
• WPEngine Bot Filter
• CloudFlare
• Web Host Server Configuration
• Firewalls

300 Errors

When you run across a 300 error, it means that the page that the HTTP POST is being made to is being redirected to another page. Infusionsoft’s HTTP POST system is fairly simple and unlike most systems cannot do redirects. If it runs into a redirect it will simply error and stop rather than going to the new URL. There are two main 300 errors, and you may run into either one; the differences between them are very subtle and unimportant for the purposes of solving this problem, and you can essentially treat them the same.

301 Moved Permanently or 302 Found / Moved Temporarily

This error is most often cause by one of two situations:

400 Errors

When doing an HTTP POST with Infusionsoft, Infusionsoft is the “client”, and your WordPress web host is the “server” If you are attempting to do an HTTP POST from Infusionsoft to your website and are running into a 400 series error, this almost always and without exception caused by a security setting on your web host or WordPress site.

401 Unauthorized

This error happens when your site or page requires “Basic Authentication” or “Basic Auth” and requires an extra username/password to access the URL. This is most commonly a setting on your web host or in a .htaccess file. It may also be generated by a plugin. It is often done when a site is under development to prevent people from viewing it. If you go to the URL in a new browser, you may see a dialog box like this come up:

If you don’t see the dialog then the restriction may be IP address based. In any case, you’ll need to either whitelist Infusionsoft’s IP address block, or disable the Basic Auth in order for the HTTP POST to be passed on to WordPress and Memberium for processing.

403 Forbidden

This error is similar to a 401 error, but the error happens when a client is not allowed to access the URL. If you’re running into this error then this is most likely a security plugin, or a security setting on your web host such as .htaccess. If it’s being generated by a security plugin, then you’ll either need to configure the security plugin to allow Infusionsoft to POST, or switch to a different plugin.

Infusionsoft no longer send HTTP posts from their static ip address. Previously, it was possible to whitelist traffic from this IP Address knowing it was coming from Infusionsoft. Currently, HTTP POST’s can be sent from a vide range of IP’s, which is why whitelisting IP won’t work.

Instead of using IP Addresses for the whitelist, you should use the User-Agent to check for Infusionsoft. Basically, check if HTTP POST header data has “Infusionsoft” (without quotes) as the User-agent.

User-Agent is a field that’s included in the HTTP POST Header. HTTP Post Header contains details about the post, such as IP address post sent from/server info/client info (the raw body contains the details of the post such as contact ID/email etc).

In order to set up the User-agent whitelist, you will need to reach out to your web hosting provider directly on how to set this up or reach out to security plugin developer/support on how to whitelist User-agent (in case you use security plugin).

In case you use Cloudflare, you shold be able to whitelist User-agent, since they already have a way of doing that:

404 Not Found

Most people are familiar with this error, and it simply means that no page is at the URL. If you’re getting this error in your HTTP POST, first check to make sure that the page you’re POSTing to exists. If the page exists and you’re getting this error then it is most likely a plugin or setting on your web host that is blocking the page from being accessed in a manner similar to a 403 error.

405 Method Not Allowed

This error is caused when your web host is configured to not allow HTTP POSTs to the URL, and only allows HTTP GET’s such as a regular web browser. This is most commonly caused by a setting in your .htaccess file.

Web Host Configuration

.htaccess

These files are usually found in the top level folder of your site and contain configuration information for your Apache web server. They usually contain a few standard lines of code for WordPress. Other plugins may add many more configuration settings here for caching or security. iThemes Security is notorious for permanently altering your .htaccess file and leaving it’s settings in place even after removal. If you have issues with your .htaccess file you may need to consult with your web host for assistance.

Security Plugins

There are a number of security plugins for WordPress that you may have installed on your site. This list includes, but is not limited to Sucuri, WordFence, and iThemes Security.

The first step is to disable all security plugins.

The second step is to examine your .htaccess file and look for configuration options that would block or redirect POSTs. iThemes Security for example does this, and leaves it’s security restrictions permanently in place even if you disable the plugin. You may have settings in here even if you have only run iThemes Security once, long ago.

The third step is to do a test HTTP POST and see if it succeeds:

If it does not succeed then there is a server configuration issue and you’ll need to contact your web host for assistance.

If the HTTP POST does succeed, then one of the plugins you disabled is blocking the HTTP POST. You’ll next want to turn on your plugins one-by-one, and re-test the HTTP POST each time until it fails again. Once it fails, you’ve found a problem plugin.

(Please refer to the “403 Forbidden” above regarding whitelist) Check your plugin’s settings for an IP Whitelist feature. If your plugin is missing this feature please contact the plugin authors and request it. If your plugin does support this feature, then you’ll want to whitelist the following IP ranges

An alternate format would be:

For iThemes Security, you’ll need to go to iThemes Security > Settings > Lockout White List, and add the above IP addresses. You’ll also need to go to iThemes security > Settings > Banned Users and uncheck the “Enable HackRepair.com’s Blacklist Feature”. Be sure to save your changes when done.

Once you’ve updated your plugin settings, re-try sending your HTTP POST. Verify that it’s working successfully before proceeding to the next plugin.

If your security plugin lacks any configuration features and the author is unresponsive or unhelpful, then we’d suggest trying one of the other security plugins listed above instead.

If you’re stuck or would like help, please contact Support so that we can help!