If 3Dsellers shows "Sorry, you cannot list resources." (woocommerce_rest_cannot_view) when you publish a product to WooCommerce, but other products on the same WooCommerce connection publish fine, the cause is almost never the API key. In the cases we have investigated, a security rule on the store's own web server (a firewall or ModSecurity rule) was rejecting the product because of ordinary words in its description, and WooCommerce then answered with its standard permission error. The fix is made on the store's hosting, not in 3Dsellers, and takes a few minutes once the hosting provider knows what to look for.

In this article:

The pattern below is what separates a server security rule from a real permissions problem. When 3Dsellers publishes a product to WooCommerce, this is what you see:

The message is generated by WooCommerce itself, inside WordPress, when a request reaches the REST API products endpoint without valid credentials. 3Dsellers 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 3Dsellers 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.

Most WordPress hosting runs a web application firewall (WAF) such as ModSecurity, Imunify360, Wordfence or a host-specific rule set. These firewalls scan every incoming request, including the JSON that 3Dsellers sends to create a product, for patterns that look like attacks. One common rule family is a generic SQL-injection heuristic that fires when it sees words like select and from in the same text.

Ordinary product copy triggers it. In the case that led to this article, the description contained "Charges select Galaxy S26 Series..." near the top and "...comfortable reach from outlets..." further down. The firewall rule (ModSecurity rule 300016 on that host) matched the pair "select ... from" and denied the request.

Here is why that shows up as a permission error instead of a firewall error:

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 3Dsellers. 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 (3Dsellers) 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 3Dsellers. 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 3Dsellers. 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 3Dsellers 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 3Dsellers carries the full description in a single JSON body, which is what the rule inspects. This difference is normal and does not mean 3Dsellers 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 3Dsellers uses is proven to work, and the error is being produced by a server-side security rule rejecting specific product content.

No. 3Dsellers 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. 3Dsellers 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 3Dsellers 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 3Dsellers error popup identifies the product inside your 3Dsellers catalog. WooCommerce assigns its own post ID only after a product is created successfully, and in this scenario the product was never created.