Compare direct REST API authentication responses to help investigate a ShipStation Consumer Key/Consumer Secret failure. This procedure is for a developer or host who can inspect the request path and WordPress HTTPS detection.
Note:
This is a Developer level doc. If you are unfamiliar working with code and resolving potential conflicts, we recommend you work with a Woo Agency Partner for larger projects, or find a WooCommerce developer on Codeable for smaller customizations. We are unable to provide support for customizations under our Support Policy.
Before you begin
↑ Back to topUse an authorized, isolated non-production environment and a disposable plugin-generated Read/Write key pair belonging to a user who can read WooCommerce system status. Use an API client that keeps credentials out of URLs, shell history, shared collections, and logs. Keep diagnostic response bodies private: they contain environment information.
If you already know the proxy forwards unencrypted HTTP to the origin, repair that path first or investigate using host logs without sending keys through it. HTTPS at the public address alone doesn’t protect the proxy-to-origin leg. Don’t weaken certificate validation or change production security settings for this test.
Compare two diagnostic requests
↑ Back to top- Send a direct GET request to
https://YOUR-STORE.example/wp-json/wc-shipstation/v1/diagnostics/details, replacing the hostname with your authorized test store. Use HTTP Basic authentication: Consumer Key as username and the matching Consumer Secret as password. - Send no WordPress login cookies, Authentication Key parameter, or
X-ShipStation-Authorizationrelay header. Those would test a different authentication path. - Record only the HTTP status and error code, with the request time. Repeat the same request with the same Consumer Key and a deliberately incorrect Consumer Secret.
- Compare the responses below, then ask your host to correlate them with the proxy/origin request and WordPress HTTPS detection.
Use the diagnostics endpoint rather than an order endpoint. Reading orders can mark them exported or add order notes. The diagnostics request reads environment information; it can update diagnostic caching and request telemetry, but doesn’t create or ship orders.
Correct secret: 200; incorrect secret: 401. This is the expected comparison when WooCommerce recognizes HTTPS and accepts the key/user permissions. The incorrect secret returns the error code woocommerce_rest_authentication_error.
Both secrets: 401, commonly with rest_forbidden. This is consistent with WooCommerce not attempting Basic authentication because it doesn’t recognize HTTPS. This result alone doesn’t identify the cause.
Other errors or identical failures. Check key validity, user permissions, forwarded Authorization headers, and proxy/security responses. Don’t assume every 401 is an HTTPS problem.
Confirm the cause and recovery
↑ Back to topCorrelate the response comparison with the amber HTTPS warning in ShipStation settings and your host’s request-path evidence. WordPress must recognize the authenticated request as HTTPS. A public endpoint returning 200 doesn’t test this permission check.
For Cloudflare Flexible mode, follow the origin HTTPS prerequisites and Full (strict) recovery steps. For another proxy, have the host correct trusted protocol forwarding. This is independent of the TLS version negotiated by the client.
Repeat both diagnostic requests after the correction. Then test the connection in ShipStation and verify an eligible order import and a shipment update. A successful diagnostic response alone doesn’t verify synchronization. Failed direct authentication isn’t added to the plugin’s Connections list; use request logs for those failures.
Remove the disposable test pair when it is no longer needed. Keep the key pair’s secret values and complete diagnostic response out of support reports. Share the request time, sanitized route, HTTP status, and error code instead.
Questions and support
↑ Back to topDo you still have questions and need assistance?
- Get in touch with a Happiness Engineer via our Help Desk. We provide support for extensions developed by and/or sold on WooCommerce.com, and Jetpack/WordPress.com customers.
- If you are not a customer, we recommend finding help in the WooCommerce support forum or hiring a Woo Agency Partner. These are trusted agencies with a proven track record of building highly customized, scalable online stores. Learn more about Woo Agency Partners.