ShippyPro & WooCommerce

Uit De Vliegende Brigade
Naar navigatie springen Naar zoeken springen

How to connect a WooCommerce site with Skippy Pro? Where to fix something when it refuses to work? How does it work?

Interface ShippyPro

  • Home » Label Creator » To Ship: Overview of orders to ship per channel
  • Home » Marketplaces: Add a new store + overview of connected marketplaces

Connections ShippyPro & WooCommerce

As of 2024.10, ShippyPro still needs the WooCommerce Legacy REST API [1]
  • ShippyPro uses REST API to communicate with WooCommerce webshops
  • As of 2024.10, ShippyPro requires the WooCommerce Legacy REST API - See screenshot
  • REST API works with keys
  • See wp-admin » WooCommerce » Settings » Advanced » REST API
  • See wp-admin » WooCommerce » Settings » Advanced » Webhooks
  • These webhooks contain user-ids & market place ids. I guess that's how Skippy Pro knows to which site an event belongs.

REST API

ShippyPro uses REST API for communication. Some background insofar as relevant for ShippyPro + WooCommerce:

Stateless client-server over http

REST APIs (Representational State Transfer Application Programming Interfaces) are a way for different systems to communicate over HTTP. They follow a stateless, client-server architecture where requests are made by clients (like ShippyPro) and responses are provided by servers (like WooCommerce). Here’s how REST APIs generally work in the context of your setup with ShippyPro and WooCommerce:

  • Client Request: The client (ShippyPro) sends an HTTP request to the server (WooCommerce) using a REST API endpoint. This request can be for various operations such as retrieving, creating, updating, or deleting resources - See next section for more on this
  • Server Response: The server processes the request and returns a response. The response typically includes the requested data or a confirmation of the operation, and it usually comes with a status code indicating the success or failure of the request - See next section for more on this
  • Stateless: Each request from the client to the server must contain all the information needed for the server to understand and process the request. The server does not retain any information about previous interactions
  • HTTP Communication happens in HTTP, usually over port 443 (using SSL). Communication over port 80 (without SSL) is quite unusual in 2024 → Let's assume it's only on port 443
  • As of the beginning of July 2024, ShippyPro uses these two IP addresses for REST API: 3.64.225.212 & 3.78.148.9

Polling

Above, it was stated that communication is initiated by the client (ShippyPro). That's not necessiraly the case, as there are two basic ways for initialising communication: polling and webhooks:

Concerning polling: ShippyPro may use a polling mechanism to check for updates. This means ShippyPro periodically sends requests to WooCommerce to check for new or updated orders. The frequency of these requests can be configured based on your needs and API rate limits. This is only possible if the firewall on the server allows incoming traffic from the IP addresses of ShippyPro. As communication is ordinary HTTP, portnumber and protocol is unlikely to be a problem.

Webhooks

As an alternative to polling, communication may be initiated by WooCommerce sites using webhooks, to notify ShippyPro about updates, like a new order.

WooCommerce confirmation URL - Procedure

Example of a confirmation URL of a WooCommerce site:

https://example.nl/wc-auth/v1/login/?app_name=ShippyPro
   &user_id=12345
   &return_url=https%3A%2F%2Fwww.shippypro.com%2Fshippypro_woocommerce_returnurl
   &callback_url=https... 
   &scope=read_write

Subsequent dialog URL:

https://example.nl/wc-auth/v1/authorize/?app_name=ShippyPro
   &user_id=12345
   &return_url=https%3A%2F%2Fwww.shippypro.com%2Fshippypro_woocommerce_returnurl
   &callback_url=https%3A%2F%2Fwww.shippypro.com%2Fshippypro_wooco...
   &scope=read_write

Connecting a WooCommerce Site to ShippyPro

ShippyPro » Marketplaces » Add your store » Click on WooCommerce icon
Fill-in dialog windows as done here. The first unchecked option, didn't seem relevant. I'm not sure about the second unchecked option
Dialog window at a WordPress/WooCommerce website: This is how the connection request is being authorized at the webshops

How to check if a connection works

  • Create an order on the WooCommerce site. Choose payment by bank transfer
  • At the backoffice, make sure that the order doesn't have status On Hold, but e.g. Processing - Otherwise the order isn't forwarded
  • The order should now occur instantly in ShippyPro.

Connection problem: Case 2024.07.09

Problem

  • It happened on nl_nl as well as on de_de
  • Since about May 2024

Potential causes

Potential causes of connection issues WooCommerce & ShippyPro since May 2024
Cause Remarks
Recent REST-API changes
  • WooCommerce/WordPress changed something about REST-API around that time
  • Not likely: Klaviyo still works + ShippyPro worked at once at de_en
Blocking/firewall (general) Seems most likely cause: Connections can be established but appearantly not used - See screenshots around here
Blocking/firewall: Apache VHDF ?
Blocking/firewall: .htaccess file
  • Some IP numbers are blocked in some .htaccess files
  • nl_nl: Removing these blocks from .htaccess didn't make a change, plus that these were actually not ShippyPro IP addresses (3.64.225.212 & 3.78.148.9)
  • nl_nl & de_de have extensive .htaccess files (and ShippyPro doesn't work) while de_en has a minimalist .htaccess file and is working fine
Blocking/firewall: WordFence ?
Blocking/firewall: CloudFlare Not likely: Only nl_nl uses CloudFlare. de_de en fr_fr don't use CloudFlare and both don't connect
Blocking/firewall: iptables Not likely: de_en works and is on the same server as most of the blocked webshops

Actions & additional information

  • Added nl_nl to ShippyPro: Connection was established straightforwardly, but no subsequent communication happened - See image somewhere around here. This site runs on separate server nltmp
  • Added de_de to ShippyPro: Same as for nl_nl although it runs on another server: hz2
  • Added de_en to ShippyPro, as this is one of the least used-sites and therefore probably one of the least-managed sites. It worked at once. See image somewhere around here: Date and time of last image is today - right now. The .htaccess file is much shorter than those for nl_nl and de_de
  • Added us_en to ShippyPro - Worked at once. Just like de_en. However, it does have an extensive .htaccess file
  • WooCommerce System Status might be an excellent starting point for on-site troubleshooting: wp-admin » Status » System status
  • WooCommerce maintains a wealth of log files - 125 at de_de as an example. Might be quite useful: wp-admin » Status » Logs. Log file webhooks-delivery for de_de indeed mentions ShippyPro, but the timestamps don't correspond with the WooCommerce REST-API screen + how come there is communication at the log file while the REST API screen says there isn't?
nl_nl: ShippyPro uses REST API to interact with WooCommerce sites. Here are a bunch of REST API keys. Note the Klaviyo key at the bottom, that actually has been used today - so REST API doesn't seem to be the problem
de_en: Here, ShippyPro connected at once. I could tell by the ShippyPro interface and here at the date of last usage - Today

Conclusions

  • At the time of this issue, I didn't write any conclusions. Now, 3 months later, I think the cause laid with changes to .htaccess
  • I probably figured that out by comparing the .htaccess file from nl_nl versus de_de.

Connection problem: Case 2024.07.25

Potential causes

Potential causes of connection issues WooCommerce & ShippyPro since May 2024
Cause Remarks
Update iptables: IP addresses ShippyPro are now blocked
  • ShippyPro IP addresses: 3.64.225.212 & 3.78.148.9
  • These were not added to iptables (sudo iptables -L -v -n)
  • Maybe traffic origin from outside the server, has been blocked more than before?
.htaccess Maybe some plugins added again stuff to .htaccess that blocks stuff

Connection problem: Case 2024.08.30

Problem

Orders fr_fr aren't send anymore to ShippyPro.

I guess this only happened recently.

Diagnosis

Potential causes of connection issues WooCommerce & ShippyPro - 2024.08.30
Cause Remarks Conclusions
.htaccess Maybe some plugins added stuff to .htaccess during a recent updates: Outside of planned updates, WordPress code cannot alter this file Removed .htaccess file - No difference
Security updates Apache
Security updates Hetzner
Strange: The REST API key has been used today, so something seems to be working

Actions

  • WooCommerce site: Removed all 4 existing keys (should have been just 1 key actually)
  • ShippyPro: Removed connection
  • ShippyPro: Recreated connection. Along the way, this conflicted with not having a .htaccess file - Restored the .htaccess file that was active before troubleshooting this issue
  • WooCommerce: Test order from earlier today (payment through invoice; status On hold): Changed status to Processing
  • → This order now (seemingly immediately) appeared in ShippyPro.

→ Problem solved - at least, for now.

Evaluation: Potential causes

  • Maybe having multiple keys, is a problem
  • Maybe ShippyPro got confused about something

Evaluation: Solution

What seemed to have been the solution: Remove the connection in ShippyPro and recreate this connection.

Deleting and recreating connections, is a very easy process and seems to be risk-free

Recommendations next time

  • Keep expanding this article and/or knowledge about this. AFAIK, ShippyPro doesn't offer any tools for diagnosing, so I really need to know this stuff myself
  • Delete and recreate the connection early on - Risk-free and it might just be the solution.

Connection problems: 2024.09

  • Orders from some sites, didn't arrive in ShippyPro, or only with a substantial delay
  • Cause: A DDOS attack drained the resources (CPU power) of this server and appearantly, communication with ShippyPro suffered from this much worse than actual webshop performance.

Sources