Question Regarding ShipStation Integration Quantity Validation Issue
-
Hi WooCommerce Support Team,
We recently encountered an issue with the WooCommerce ShipStation Integration plugin where orders stopped importing into ShipStation. The error returned was:
“Input string ‘1.125’ is not a valid integer (sales_orders[].requested_fulfillments[].items[].quantity).”
Our store uses measurement-based products that can produce decimal quantities, and we had previously implemented logic to convert those quantities to integers before export. This had been working correctly until today, and no changes were made on our side before the issue started.
During troubleshooting, we noticed that even though the XML export logic was adjusted, the failing value appeared to be coming from the REST payload builder instead of the XML export endpoint.
After adjusting the REST payload logic, the orders began importing correctly again.
Before we send a more detailed report, could you please confirm whether there have been any recent changes in the WooCommerce ShipStation Integration plugin related to order export or payload generation?
Thank you.
Sarun
-
Hi @sarunraj,
Thank you for the detailed explanation and for walking through the investigation you carried out. It is great to see the steps you took to trace the issue back to the REST payload builder and confirm that adjusting the logic allowed orders to start importing again.
At this time, there have not been any broadly reported recent changes in the ShipStation for WooCommerce plugin specifically related to order export or payload generation that would affect quantity handling in this way. The plugin expects quantities to be integers, as required by the ShipStation API, so decimal values can sometimes lead to validation errors like the one you encountered.
If you would like us to take a closer look, it would help to review a few additional details from your environment. Please share the following:
- Your System Status Report. You can find it via WooCommerce → Status → Get system report, then copy the report and share it using https://pastebin.com, https://quickforget.com, or https://gist.github.com and post the link here.
- The WooCommerce version and ShipStation for WooCommerce plugin version currently running on your site.
- If possible, the payload or code snippet related to the quantity handling you adjusted. Longer snippets can also be shared via the paste services above.
For reference, you can also review the integration documentation here: https://woocommerce.com/document/shipstation-for-woocommerce/
Once we have the report and a bit more context, we can help check if anything in the environment or recent updates may have influenced the behavior.
Hello,
Thank you for your response. I would like to provide additional context regarding the issue we are currently experiencing with the WooCommerce ShipStation integration.
Our store sells measurement-based products (fabric) where customers can purchase fractional quantities (for example: 0.25, 0.375, 1.25 yards). WooCommerce supports decimal quantities for these products, but ShipStation requires integer quantities. Previous implementation (XML export)
Previously, the ShipStation integration exported orders using the XML export format. To handle measurement-based products, we implemented a customization in the ShipStation plugin to convert the quantity to
1during export so ShipStation could process the order.The customization was applied in the following file:
plugins/woocommerce-shipstation-integration/includes/api/requests/class-wc-shipstation-api-export.phpThis solution worked reliably for a long time. Current situation (REST API export)
Recently we noticed that the ShipStation integration appears to have switched to a REST API payload instead of the previous XML export, and this change seems to have occurred without any notice.
Because of this change, our previous customization stopped working and we began seeing errors such as:
Input string ‘0.375’ is not a valid integer.
Path ‘sales_orders[…].returns[0].total_quantity’To resolve this, we added a filter to convert fractional quantities to
1before they are sent to ShipStation.The code currently used on the site is here:
https://gist.github.com/sarun007/04ad18cf287a7c19dba82c62b49fed22 Current behaviour
After implementing this fix, orders generally import correctly into ShipStation. However, we are still occasionally seeing intermittent errors reported by ShipStation related to quantity validation.
This creates some uncertainty about whether the integration is fully handling fractional quantities correctly under the newer REST-based export. Questions
Could you please clarify the following:
- Has the ShipStation integration officially transitioned from XML export to REST API payloads?
- Is there a recommended or supported method for stores that sell measurement-based products with fractional quantities?
- Should quantities be normalized before export, or is there a built-in hook/filter in the plugin intended for this use case?
Additional information
System Status report:
https://quickforget.com/s/ba45cd30156e139e66cdf95b2b40bb98d5b5c4905bc73ac9We would appreciate any guidance on the correct approach for handling decimal quantities with the current ShipStation integration.
API Payload Response : https://gist.github.com/sarun007/1bcaa92a6dc698e186b9b35316772196
Thank you for your assistance.
Sarun
Hi @sarunraj,
Thank you for the very detailed explanation and for sharing the additional context, links, and the System Status Report. It is clear you have done quite a bit of investigation already, especially tracing the issue to the REST payload builder and implementing a filter to normalize the quantities before they are sent to ShipStation.
To address your questions, the ShipStation for WooCommerce integration has for some time relied on the API based communication with ShipStation rather than the earlier XML export approach. Because of this, customizations made specifically in the XML export class may no longer affect the payload if the order is being prepared through the REST based request builder. Your observation that the value was coming from the payload builder rather than the XML export logic aligns with how the plugin currently prepares order data.
Regarding fractional quantities, ShipStation requires thequantityfield to be an integer. When WooCommerce stores measurement based products with decimal quantities, these can trigger validation errors like the one you encountered if they reach the payload unchanged. Because of that requirement, stores that sell measurement based products typically normalize the quantity before export, similar to the filter you implemented, and pass the measurement details through the line item name, metadata, or description so the fulfillment side can still identify the exact measurement ordered.
At the moment there is no dedicated built in setting in the plugin specifically designed for fractional quantity products. Customizing the payload before it is sent to ShipStation, using filters or custom logic, is generally the approach used for these scenarios.
For additional reference, you can review both the documentation and the plugin changelog here: https://woocommerce.com/document/shipstation-for-woocommerce/ & https://wordpress.org/plugins/woocommerce-shipstation-integration/#developers. The changelog can help confirm whether any recent updates may have affected how order payloads are generated.
Since you are still seeing occasional validation errors, it may help to compare the payload from one of the failing orders with a successful one to confirm whether a decimal quantity is still reaching the request before the normalization logic runs.Hi @lovingbro
Thank you again for the detailed explanation regarding the REST payload builder and the fractional quantity handling. That clarification helped us understand how the plugin currently prepares the order data.
After applying the quantity normalization filter and reconnecting the ShipStation store, we continued monitoring the logs together with the customer. During this testing we noticed a consistent pattern related to automatic import (unattended import) on the ShipStation side.
Previously, when automatic import was enabled, the customer observed that whenever the unattended import ran:
- Validation errors would start appearing.
- Older orders that had already been processed would show up again in the logs.
- In some cases, the import process would stop or fail shortly after the automatic import ran.
Before our last reconnection, the customer disabled automatic import in ShipStation and switched to manual imports only. Since then:
- Manual imports are working consistently.
- No validation errors have appeared.
- No previously processed orders are being logged again.
- The logs remain clean.
From a technical perspective, we wanted to ask a few questions to better understand what might be happening:
- Does automatic (unattended) import use the exact same request flow and payload builder as manual import, or are there differences in how the order synchronization is triggered?
- When automatic import runs, does ShipStation sometimes re-check or re-request previously imported orders, which could explain why older orders started appearing in the logs?
- Could automatic import trigger a broader synchronization window compared to manual imports?Is it possible that automatic import calls a different API request or payload structure compared to manual imports?
Everything is currently working correctly with manual imports, but we would appreciate any clarification on how automatic import behaves internally so we can better understand the root cause.
Thank you again for your assistance.
Best regards,
SarunWe are still facing an issue related to the Substation integration.On the store connection page, an error message is being shown
https://prnt.sc/h31LKqvH0VYwHowever, when we try to manage the import, the products are still getting imported into Substation.Based on our checks, it looks like the plugin is still sending incorrect data to Substation during the automatic import process. Because of this, we are seeing unexpected quantities being created in Substation.Could you please check this from your side and let us know:
Why the plugin is still sending incorrect data during the automatic import.What might be causing this issue.How we can fix or prevent this from happening again.
Please review and let us know your findings.Thank you.
Hello Sarun,
Thanks for sharing the screenshot. We are looking into this and the details you’ve previously shared at the moment; it’s taking a little time but we’ll be sure to get back to you once we have a further update for you.
Best regards!
Hi Sarun,
I was experiencing the same error, found this thread, tried your code, but ended up with the same “0.375” error.However, I was just able to reconnect and sync our site with ShipStation after disabling the plugin “Advanced Product Quantity”. Are you by chance using that, too? I haven’t dug into its code to see where the problem lies and I have yet to see if the problem will reoccur after reenabling it, but wanted to pass this along.
Hi @sarunraj
Thank you for your patience while we investigated this further, and thank you again for the thorough research you shared throughout this thread.
You are correct that the transition to the REST API payload builder in version 4.9.0 changed how order data is sent to ShipStation. The REST API export path sends the raw quantity value from WooCommerce without casting it to an integer. For stores like yours that sell measurement-based products with fractional quantities, this means values like 0.375 or 1.125 reach the ShipStation API, which requires integer quantities. This is a gap in the plugin that we need to address.
That said, both automatic and manual imports use the same API endpoint and code path in the plugin. The difference is that automatic imports typically request a larger batch of orders across a wider time window, which increases the chance of including an order with fractional quantities in the refund or return data. If any single order in the batch fails ShipStation’s validation, it can cause the entire batch to be rejected. With manual imports, you are likely pulling smaller, more targeted batches, which is why they succeed more consistently.
We have raised this directly with ShipStation. They confirmed that they do expect quantities to be integers. They are currently deciding internally how they want us to handle fractional quantities in the plugin, whether that means sending a minimum of 1, rounding, or another approach. Once we have their guidance, we will implement a proper fix in the plugin so that stores with measurement-based products work correctly without requiring custom code.
Furthermore, your filter code is well-written and is the correct approach for now. To address the remaining intermittent errors, you may need to extend your second filter (
woocommerce_shipstation_orders_controller_get_order_data) to also normalize any quantity values in the full order data array before it is sent. This would catch the returns path that the fulfillment item filter does not reach. For example:add_filter( 'woocommerce_shipstation_orders_controller_get_order_data', function( $order_data, $order ) {
if ( isset( $order_data['status'] ) && 'Unknown' === $order_data['status'] ) {
$order_data['status'] = 'AwaitingShipment';
}
if ( ! empty( $order_data['returns'] ) && is_array( $order_data['returns'] ) ) {
foreach ( $order_data['returns'] as &$return_item ) {
if ( isset( $return_item['total_quantity'] ) && is_numeric( $return_item['total_quantity'] ) ) {
$qty = (float) $return_item['total_quantity'];
if ( abs( $qty - round( $qty ) ) > 0.000001 ) {
$return_item['total_quantity'] = max( 1, (int) ceil( $qty ) );
}
}
if ( ! empty( $return_item['items'] ) && is_array( $return_item['items'] ) ) {
foreach ( $return_item['items'] as &$item ) {
if ( isset( $item['quantity'] ) && is_numeric( $item['quantity'] ) ) {
$item_qty = (float) $item['quantity'];
if ( abs( $item_qty - round( $item_qty ) ) > 0.000001 ) {
$item['quantity'] = max( 1, (int) ceil( $item_qty ) );
}
}
}
unset( $item );
}
}
unset( $return_item );
}
return $order_data;
}, 10, 2 );This replaces your existing second filter and adds handling for the returns data in addition to the status fallback.
We will follow up on this thread once ShipStation has confirmed their preferred approach and we have a plugin update ready.
Thank you again for your detailed reports. They made a real difference in diagnosing this.
It seems we haven’t heard back from you for a while, so I’ll go ahead and mark this thread as resolved. Feel free to reach out whenever you’re ready to continue.
If you have a few minutes, we’d love if you could leave us a review: https://wordpress.org/support/plugin/woocommerce-shipstation-integration/reviews/
You must be logged in to reply to this topic.
