We ship on behalf of 14,000 online sellers, each wanting their own return address on the label. So far this has necessitated the creation of 14,000 ship from locations.

We are opening a second location (that we ship from), and now we need a second ship from location, also able to ship with the return address of our 14,000 partners. In the current structure this will necessitate 28,000 ship from locations.

It would be ideal if we could independently set the location to get the shipping RATE from, separately from the return address on each order.

This would allow us to simply pass in any return address, and rate location for each order and it would provide much better support for when you are shipping from multiple place for multiple people.

I originally opened a support case over this, but was told the API's behavior was "as intended," and I should instead submit feedback, or a feature request over it, so here I am.

The Product Open API call is incorrectly programmed, and I'm requesting that it be fixed.

Here's three scenarios that prove it (screenshots attached):
1. The product with an assigned shipping preset group, but no default shipping settings.
2. The product with no assigned shipping preset group, but with default shipping settings.
3. The product with both an an assigned shipping preset group, and with default shipping settings.

Here's what I've noticed: If there is a shipping preset group assigned, the API call will populate this information in the "productType" section (which, I'll add, is not a very good name for what it is). BUT, if there's defaults in the product itself, those default will overwrite the productType settings. I don't think this is supposed to happen, especially because it's not just the shipping attributes that are being overwritten, the NAME itself is also being overwritten.

Let's look at scenario 1.
A preset group is assigned, so the API call returns a productType section, with an array of data. In that array of data, you'll see what the preset's assigned service, package, and weight are (highlighted in blue). HOWEVER, the name of the preset group, which is "z [Preset] 08 fl oz (Plastic)," does not display. Instead, it displays the product name. Why doesn't it display the preset group name?

Let's look at scenario 2.
A preset group is not assigned, so the API call returns null for productType. The default assignments (in red) can be seen as part of the product details above (for weightOz), and below (for defaultServiceCode and defaultPackageCode).

Finally, let's look at scenario 3.
A preset group IS assigned, so the API call returns a productType section, with an array of data. It's the same preset group, so it should be displaying the same data you see in scenario 1. But it doesn't. The preset group's attributes in the productType section of the API call (still highlighted in blue) are instead displaying the product's defaults (still highlighted in red). But why? Why return this information twice?

Here's my explanation:
If the API call sees that a preset group assignment exists, it returns the information from that preset group, based on its ID. BUT, if the product has defaults assigned, the product's attributes are displayed instead, and I don't think this is intentional. I especially believe this because the NAME is being taken from the product, too, instead of being taken from the preset group. Why would that be intentional behavior?

Sure, you could argue "oh, it's because the product's default shipping settings are overwriting the preset group's settings," but why the name, too? That doesn't make any sense, and it to me, it just indicates that the API is programmed incorrectly. It might be happening because the attribute names (weightOz, defaultCarrierCode, name, etc) are the same in Product and in ProductType/PresetGroup.

My request:
Fix the API call. The productType section should only, and always, display information from the preset group. If the product itself has defaults, they're already being displayed in the red-highlighted areas, so there's no reason to return them overwritten in the productType section.

At least fix it so it actually displays the preset group's name, because there's no way I'll believe it's intentionally displaying the product name there on purpose.

I've been trying to learn a little about reorder points for product. I have been guessing (wrong!) and so I did a little research until I found what I needed in its simplist form
https://www.fishbowlinventory.com/reorder-point-calculator/
and it occurred to me that it might be easy for ShipStation to offer a reorder alert. The customer could find this feature somewhere in ShipStation, illustrate the formula (automation is great, but I like to know WHAT is getting automated and how), then ask what are typical numbers for inventory, then the formula could update these numbers overtime & automatically adjust them--how many are REALLY get sold every 30 days? 98.1 instead of 100?

When inventory is getting low, ShipStation could have a pop-up alert on its Order Page.