"Sorry, you cannot list resources." (woocommerce_rest_cannot_view, status 401) is WooCommerce's permission error, but when it hits one or two products while the rest of your catalog publishes normally from EasyChannel, permissions are not what is wrong. A web application firewall on the store's server, typically a ModSecurity rule, is rejecting those products because of harmless words in their descriptions, and the server's error handling makes WooCommerce reply as if the request had no API key. Your hosting provider fixes it with a small, scoped rule exception; nothing needs to change in EasyChannel.

In this article:

Check the failed publish in EasyChannel against this list. Four or five matches means you are looking at a server firewall rule, not a WooCommerce permission setting:

The message is generated by WooCommerce itself, inside WordPress, when a request reaches the REST API products endpoint without valid credentials. EasyChannel passes it through unchanged. The full response your store sends back looks like this:

{"code":"woocommerce_rest_cannot_view","message":"Sorry, you cannot list resources.","data":{"status":401}}

Taken literally, it says "whoever sent this request is not allowed to read products". That is why the first instinct is to check the API key. But EasyChannel sends the same consumer key and secret for every product on the connection, so when only some products fail, the credentials cannot be the reason. Something on the store side is turning a valid, authenticated create request into an unauthenticated one before WooCommerce evaluates it.

If every product on the WooCommerce connection fails with this error, it usually is a permissions problem. Check these three things in your WordPress admin before anything else:

If all three are correct and other products publish fine, the API key is not the problem. Continue below.

Almost every WordPress host puts a web application firewall in front of the site: ModSecurity on cPanel and Plesk servers, Imunify360, Wordfence, or the host's own rule set. The firewall reads the body of every request before WordPress does, and the product JSON that EasyChannel sends is no exception. Among its rules is usually a broad SQL-injection check that reacts to the words select and from appearing anywhere in the same piece of text.

Marketing copy sets it off. The seller whose case produced this article had a description that opened with "Charges select Galaxy S26 Series..." and later mentioned "...comfortable reach from outlets...". ModSecurity rule 300016 on their server saw "select ... from", classed the request as an injection attempt, and refused it. Nothing about the product was unusual.

The reason you see a WooCommerce permission error rather than a firewall block is the chain of events that follows the refusal:

The fix is a scoped exception on the store's server so that the firewall rule does not apply to the WooCommerce products endpoint. Nothing changes in EasyChannel. There are three ways to get there, from best to quickest:

If you manage the server yourself: find the rule ID in the ModSecurity audit log entry for the failed request, then add a location-scoped SecRuleRemoveById for that ID on the products endpoint. If your host manages ModSecurity for you (cPanel, Plesk, managed WordPress), open a ticket and send them the text in the next section.

Copy this into your hosting ticket and fill in the two blanks. It gives the host everything they need to find the rule in one pass.

"Product creation requests from our multi-channel listing tool (EasyChannel) to /wp-json/wc/v3/products are being denied by a web application firewall rule on our server and re-served as an unauthenticated request, so WooCommerce returns 401 woocommerce_rest_cannot_view ("Sorry, you cannot list resources."). Other products on the same API key publish successfully, so the key is fine. The failing requests are authenticated POSTs with a JSON body of about 4 KB that contain ordinary product descriptions. Please check the ModSecurity (or equivalent WAF) audit log around [DATE AND TIME OF THE FAILED PUBLISH] for a rule hit on that endpoint, most likely a generic SQL-injection rule matching words in the product description, and add a scoped exception for that rule ID on /wp-json/wc/v3/products only. The product SKU affected is [SKU]."

The failed request time is shown on the error in EasyChannel. Give the host the exact minute; firewall logs are large and a time window makes the search fast.

Once the host confirms the exception is in place, publish the product again from EasyChannel. You do not need to delete it in WooCommerce or re-import it. A successful publish returns status 201 Created from the store and the product moves to a live state in your EasyChannel catalog. If it fails with the same error, the exception is not covering the products endpoint yet, or a second rule is firing; send the host the new failure time.

This is a permissions problem, not a firewall rule. Go back to "Rule out the simple causes first": check the API key is Read/Write, the WordPress user behind it can manage products, and the connection uses the current key.

That is the expected signature of this problem, not evidence against it. The CDN passes the request through untouched, the WordPress and PHP error logs never see a rejected request, and the access log only records the final 401. Ask the host specifically for the ModSecurity or WAF audit log.

Manual creation goes through the WordPress admin, a different path with different firewall rules, and often a shorter or differently formatted description. The API request from EasyChannel carries the full description in a single JSON body, which is what the rule inspects. This difference is normal and does not mean EasyChannel is sending bad data.

The diagnosis is confirmed, but the rule is still active. The next product whose description happens to contain the same word pair will fail the same way. Ask your host for the scoped exception so you do not have to police product copy.

Consistent with this cause. In the investigated case the rejected requests took 1.7 to 1.9 seconds against about half a second for a normal request, because WordPress ran twice (once for the original request, once for the internal re-run). It is a useful hint to give the host.

Only when every product on the connection fails. When other products on the same WooCommerce account publish successfully, the API key EasyChannel uses is proven to work, and the error is being produced by a server-side security rule rejecting specific product content.

No. EasyChannel sends a standard, authenticated WooCommerce REST API create request, the same one that succeeds for the seller's other products. The rejection happens on the store's own server before WooCommerce evaluates the request. EasyChannel cannot change a hosting provider's firewall rules, which is why the fix has to be made on the store side.

It depends on the rule set your host runs. The confirmed case was a generic SQL-injection heuristic reacting to "select" and "from" appearing in the same text. Other common triggers in the same rule families are "union", "insert", "update ... set", "drop", "script" and long strings of quotes or parentheses. Do not try to write around these; ask for the scoped exception instead.

A scoped exception limited to /wp-json/wc/v3/products leaves SQL-injection protection fully active on every other part of the site, including checkout, login and the WordPress admin. The products endpoint already requires a valid WooCommerce API key to do anything, so the exception only affects authenticated API clients such as your listing tool.

Not on its own. Retrying from EasyChannel fails identically every time, because the firewall rule is deterministic: the same description produces the same rejection. Retrying only makes sense after the rule exception is in place on the store.

Because it is not a WordPress post ID. The Item ID in the EasyChannel error popup identifies the product inside your EasyChannel catalog. WooCommerce assigns its own post ID only after a product is created successfully, and in this scenario the product was never created.