I currently use Linnworks Warehouse Management Software to process all of my orders from numerous sales channels. This allows me to keep accurate inventory across multiple sales channels and keep accurate records of sales. Which is why I have Linnworks integrated with ShipStation as a Store. All of the shipping is purchased through Linnworks Store, then processed on the Software.In most cases I use USPS and UPS, so it's not a problem doing it within the Linnworks Store integration. However, when I ship Merchant Fulfilled Amazon Orders, I use the Amazon Buy Shipping method.The problem with trying to do it within the Linnworks Store integration is that I get a rate error because it is looking at the order number (which is Linnwork's order number) but it doesn't match Amazon's order number format ( [0-9A-Z]{3}-[0-9]{7}-[0-9]{7} ). So, I have to place the order on the Amazon Store integration, and then copy/paste the tracking number into the Linnworks Store integration, which is a big waste of time.However, I have the Amazon order number in the Custom Field 1 section of the notes. Please add a feature where I can have the custom field be a order number reference for Amazon Buy Shipping.
There is an Action Type to "Enable Saturday Delivery", but to use this action well, we need a criteria that basically says "If today is Friday and ______ premium shipping service was selected". I understand this may be difficult because you'd constantly need to check the date and reprocess the rule, so perhaps this is something that is triggered when doing the create and print label command? Or if that's impossible, perhaps the ability to say "if order date is between Thursday 3pm and Friday 3pm" or something of that nature to dial in on which orders will generally be shipped on a Friday, so we can selectively add the Saturday delivery option to orders that a customer has requested a shipping service where they expect it will be delivered on a Saturday.Since this option doesn't exist, we have to either pay the extra $15 Saturday delivery charge every order, or else manually enable it for certain orders when shipping out on a Friday. Usually this results in very angry customers because we forgot to check the box. My business sells parts that fix peoples' cars. They're not happy when they don't get their parts on Saturdays and have to miss work Monday because of a checkbox ><
We are currently using ShipStation UPS account, however when we used to use our own, we would get emails throughout the day when there was a delivery exception notice from UPS about a package. They would allow us to log in and make any corrections instead of having the package shipped back to us. This allows for less customer abrasion if they forgot to provide a space, building, or apartment number.
Hello, It would be very helpful if there was the option to update shipping records via CSV imports.
When a user cancels an order in Shipstation, Shipstation should call the endpoint setup in the selling channel just like it does when a tracking number is available and pass order status cancelled. This should be a very easy mod for Shipstation developers and it would save my company thousands of man hours per year. Right now we have to train hundreds of warehouse workers to use multiple systems which is really NOT good or efficient. Cancel means cancel. Please add this feature. This would benefit every Shipstation user.
We try to set up an automation rule for 'shipping from' for different stores . When I add 2 criteria (order from 2 stores), the automation didn't apply. I contacted customer support and Julio told me that I had to split the 2 criteria into 2 rules. It does work after I created 2 rules. But it make no sense that one automation rule could only have 1 criteria.
Buy a FedEx or USPS shipping label at the best price, through Seller Center or Walmart APIsCan we get on this?Please reach out . I have the API info on the intro email.Thanks -Ike
You currently support Parcelforce services including Euro Priority and Global Priority, but you do not have Global Express unfortunately. This is Parcelforce’s fast service, which offers 1-2 day delivery to most locations worldwide. An increasing number of customers are now asking for this, so we need to be able to do these orders from within ShipStation. Given that you already support other Parcelforce shipping methods I don’t imagine it would a huge effort to add Global Express.
I am a new business in the US. I am offering free shipping to people in the intercontinental U.S. I would like to give a discount of $5 to international customers to offset their costs. Thoughts from others?
ShipStation is no longer allowing us to send Parcels to Jersey via ParcelForce. We can use myHermes for smaller Parcels but for larger orders we need a different carrier. I have been informed that this is because the country code is JJ in ParcelForce rather than JE like other carriers. We now have to manually input orders using our ParcelForce account which is time consuming and defeats the point of us using ShipStation. Do you know when this can be resolved??
Hello. Please implement passing Etsy Gift message to FBA "Packing slip comments" field. This will help very much. All the Gift messages Etsy buyers are leaving now, are just ignored by Shipstation. It receives the message with an order from Etsy, but is not passing it to FBA for fulfillment, and to include in the packing slip. Manually it is possible. And automatically via Shipstation, it looks like there is only one simple step is missing.Thank you!
We have hundreds of shipping profiles for our products. If I can't find the profile fast this whole preset is completely useless. It takes less time for me to enter the shipping dimensions for an SKU faster if I enter manually. I am talking about the "Add Preset Group" under this link:https://ship11.shipstation.com/products
11-15-2021 --After creating a label / labels, Shipstation returns me to the "Awaiting Shipment - all Orders" view. This is completely unnecessary and slows down processing my orders. The previous version simply "grayed out" the orders I shipped and kept me at my current view, which was a much better solution.Being able to organize orders into multiple batches, even within the same store // interface view, is crucial to how my business processes orders. Adding these extra "Return to view" steps for each batch makes daily operations take significantly longer.
My business recently updated to v3 of Shipstation. We have many stores, and currently have to update the Column Headers shown for each individual store. We also have multiple users, and need to update the Column Headers for each individual user.If this is to stay as is, I recommend allowing us to update the "Default Columns", and then we can update individual stores/users when they are different from the default. Otherwise, I recommend an "Update subsections" option -- For Example, when updating the columns for "Awaiting Shipment - All Orders", have a checkbox to update all sub-sections (stores).There is also the ability to save a View, however, Views also only save to one store and one user -- Which makes no sense to me. Why not allow a view to be applied anywhere after saving it?
Shipping costs alert- make and alert where shipping cost (Cost-what customer paid) exceeds 15% of the product price
This is a small issue, but it looks bad for us that a branded returns page for a UK business asks for Zip Code. If I encountered that page, overall, I'd wonder if it was a bad phishing attempt. It would help if you could localise the page so it says Postal Code. Thanks.
Currently, products identified by the ecommerce platform as digital products are not synced to ShipStation as line items.While I understand that digital products do not require physical shipment, excluding them entirely from the ShipStation order creates a significant data-integrity problem.When an order contains both physical and digital/non-shippable products:The digital products do not appear in the ShipStation order details. The order total displayed in ShipStation does not reflect the customer's actual order total. Packing slips and other ShipStation-generated documents do not show all products the customer purchased. Documents generated from ShipStation can therefore contain incomplete itemization and totals that do not match the originating ecommerce order. Other applications and automations that rely on ShipStation order data also receive incomplete or inaccurate information.There is an important difference between not requiring shipment of a product and removing that product from the order record entirely.Ideally, digital/non-shippable products should still sync to ShipStation and remain visible as order line items, while simply being identified as non-shippable or excluded from shipping calculations.I have discussed this issue extensively with ShipStation Support and was advised that customers need to submit this as a feature request. Support also suggested manually monitoring incoming orders for digital products and then manually editing each affected ShipStation order to add the missing items and correct the order total.For businesses processing a significant volume of orders, this is not a practical or scalable workaround. It would require staff to compare ShipStation orders against the originating ecommerce orders simply to verify that the imported data is accurate, and then manually correct any discrepancies. In addition to the administrative burden, this introduces another opportunity for human error. One of the primary purposes of an ecommerce integration is to eliminate this type of manual reconciliation.Customers should not have to manually verify and reconstruct imported orders in order for ShipStation's order records and documents to match the ecommerce transaction.I believe this goes beyond simply adding support for digital products. When ShipStation imports an ecommerce order, the resulting order record should accurately represent the transaction that occurred in the ecommerce platform. A customer purchasing four products should not appear in ShipStation as having purchased only three simply because one product does not require physical fulfillment.Please consider allowing all order line items to sync to ShipStation, including digital/non-shippable products, while separately identifying which items require fulfillment. This would preserve accurate order totals, customer-facing documents, reporting, and downstream integrations without requiring digital products to be treated as shippable items.
ShipStation should use the actual ship date entered in the order’s shipping details when generating customer communications and transmitting shipping information to other applications.Currently, ShipStation may display the date that shipping or tracking information was entered or updated rather than the date the order actually shipped. These dates are not necessarily the same.This is particularly problematic with drop-shipped orders. A supplier may ship an order on one date but not provide the tracking information to the merchant until several days later. When the merchant receives the tracking information, the correct ship date can be entered in the order’s shipping details. However, ShipStation correspondence may still report the later date on which the shipping information was entered or updated as the ship date.For example, an order may actually ship on August 10, with the drop shipper providing tracking information on August 13. If the order is updated on August 13 and ShipStation reports August 13 as the shipping date, the customer is being given inaccurate information even though the correct August 10 ship date has been entered in the order.This creates several problems: Customers receive inaccurate shipping information. The communication states that an order shipped on a date when it did not. Delivery expectations become misleading. A customer may believe a package has only been in transit for one day when it has actually been in transit for several days. Incorrect information is passed to integrated applications. Other systems that rely on ShipStation data may then store, display, or communicate the inaccurate shipping date. This includes data passed back to the ecommerce platform, where the incorrect ship date can affect downstream order logic. It undermines the purpose of having a ship-date field. If the merchant has entered the actual ship date in the order's shipping details, that date should be treated as the authoritative shipping date rather than the date on which the information happened to be entered into ShipStation. It can cause return windows to be calculated incorrectly. Many ecommerce platforms calculate return eligibility based on the shipment date. If ShipStation sends the date the tracking information was entered rather than the actual ship date, the ecommerce platform may begin the return window from the wrong date, resulting in an inaccurate return deadline. It creates unnecessary customer-service issues. Customers may question tracking activity, expected delivery dates, return eligibility, or apparent discrepancies between carrier tracking and the information provided by the merchant. The date that shipping information is entered or updated is an administrative timestamp, not necessarily a shipping event. These are two different pieces of information and should not be treated interchangeably.For data accuracy, ShipStation should consistently use the ship date recorded in the order’s shipping details in customer correspondence, API/integration data, data returned to the ecommerce platform, and other downstream communications whenever that date has been provided. The date the shipping information was entered or updated can certainly be retained internally for auditing purposes, but it should not replace the actual ship date communicated to customers or connected systems, particularly when that date is used to calculate time-sensitive policies such as return windows.
Some customers require parcels and pallets to be labeled with GS1-128 (UCC-128) logistics labels.It would be helpful if ShipStation could produce these labels.Specifications can be found here.
Currently, existing name/address blocks of text cannot simply be pasted into a manual order (as they could, for example, in the DAZzle app of Endicia, now long gone).They cannot simply be pasted because ShipStation (ss) insists on parsing them into separate fields. If ss simply added another name/address block input field, all the problems would be solved by simply sending the block as-is to the shipping provider.It is impossible to list all the problems with the current input field, but some are as follows:International addresses are not actively rejected, but often difficult manual intervention is needed to fit a UK or Canadian or Hong Kong addressing scheme into fields meant only for U.S. addressing: address, city, state, zip code. It is ridiculous that a shipping product has a policy of not providing any way to enter international addresses properly, without meddling. Sometimes the name is parsed into the name field correctly, sometimes into the Company field. This choice seems random. An internal handling code appended to the end of the name often disappears or is moved to another field. No provision is made to accept internal handling codes. We pack different contents according to the code we provide in the name/address block. Once in a long while, no manual intervention is needed to correct ss’s meddling. Addressing is done perfectly. This is occasion for great celebration in our office. Our parties at these times are memorable.
We would like to see multi-package details added to shipment report capabilities without having to go to each individual shipment and click on multi-package.
Hi Can we add walmart buy shipping to buy directly through shipstation, same as you have for amazon?
Hello ShipStation team,We would like to request a new automation option for insurance value calculation.🚨 Current limitationAt the moment, ShipStation insurance automation only allows:“Automatically insure all shipments” Insurance value is calculated based on Order Total (pre-discounts / system total) There is no automation option to use Amount Paid as the insured valueThis creates inconsistencies across multi-channel orders.⚠️ Problem we are facingWe sell across multiple platforms (WooCommerce, Amazon, Walmart, TikTok Shop), and we rely on accurate insurance based on the actual amount paid by the customer.However:Order Total ≠ Amount Paid (due to discounts, promos, taxes, partial adjustments) Manual edits are currently required to correct insured values Automation is not reliable or consistent across channels Some orders appear correct only after manual adjustment, which is not scalable🎯 Desired functionalityWe would like ShipStation to support:✔ Insurance automation based on Amount Paid✔ Option to select insurance calculation source:Order Total Amount Paid Item Subtotal Custom field (advanced/API if available)✔ Consistent behavior across all sales channels and marketplaces📌 Why this mattersFor high-volume multi-channel sellers, using Order Total can lead to:Over-insurance (extra unnecessary cost) Under-insurance (financial risk in claims) Manual corrections that do not scale Inconsistent insurance logic across ordersA simple field selector would fully solve this.🙏 RequestPlease consider adding “Amount Paid” as an available field for insurance automation rules, or exposing this via API/advanced configuration.This would significantly improve accuracy and automation reliability for multi-channel merchants.Thank you.
It seems to me that a lot of people are asking for the same thing. In general, I believe shipstation needs automation that is triggered after a specific event that is chosen by the user. The trigger can/should be anything like the scale readout, a tag being assigned to an order, something being printed (like the pick slip or packing slip or even Shipping label), and everything in between.
Already have an account? Login
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
