[BUG] value_ids field of updateListingProperty sometimes cannot be valued

[FloderCC]

Hello, This updateListingProperty call requires the value_ids field. But this field does not have available values for many of the properties returned by getPropertiesByTaxonomyId. This happens for example for numeric properties like 'Height' etc. I have tried value_ids = null, value_ids = [], value_ids = [0] and value_ids = [1], and in all cases the API returns errors like 'Missing input parameter: [value_ids]', 'IDs must be> = 1 , got 0 'or,' Server Error '. My test case is taxonomy_id 871 and property_id 505 Greetings

[stickfigure]

Yikes, I just hit this in production after rolling out the v3 API migration (the case wasn't covered by my test suite). My example is that Mugs have a property for Volume/Capacity, but there are no values for it.

Taxonomy id 1062, property id 52047898162 looks like this:

    {
      "property_id": 52047898162,
      "name": "Volume",
      "display_name": "Capacity",
      "scales": [
        {
          "scale_id": 37,
          "display_name": "Fluid Ounces",
          "description": ""
        },
        {
          "scale_id": 36,
          "display_name": "Liters",
          "description": ""
        },
        {
          "scale_id": 35,
          "display_name": "Milliliters",
          "description": ""
        }
      ],
      "is_required": false,
      "supports_attributes": true,
      "supports_variations": true,
      "is_multivalued": false,
      "possible_values": [],
      "selected_values": []
    },

No possible_values. How can we apply this property if updateListingProperty always requires the value_ids field?

[etsyachristensen]

@stickfigure I'm looking through this now.

[etsyachristensen]

@stickfigure I finally got to the bottom of this... So with this type of variation, the possibilities for the volume are of course endless. The value could be an integer or a decimal value and via the API you can set just about anything for that volume.

The V2 API documentation says that you have to include either "values" or "value_ids" arrays or both. The V3 documentation is a bit misleading saying that both arrays are required and I'll correct that. It's one or the other or both, just like V2.

But of course you would have no way to know the value_id to a volume that you are setting ahead of time and the api won't give you that information really.

So the answer to your issue is to leave the "value_ids" array EMPTY. Pass it as []. The API will actually fill in the value_ids on it's response back when the inventory is saved.

For example, here's the property_values of an entry I just tested with (note that the number for the ounces - 53 - is encased in quotes, making it a string.):

            "property_values": [
                {
                    "property_id": 18107483622,
                    "property_name": "Capacity",
                    "scale_id": 37,
                    "value_ids": [],
                    "values": ["53"]
                }
            ]

And the response from the API gave this:

            "property_values": [
                {
                    "property_id": 18107483622,
                    "property_name": "Capacity",
                    "scale_id": 37,
                    "scale_name": "Fluid Ounces",
                    "value_ids": [
                        18164300084
                    ],
                    "values": [
                        "53"
                    ]
                }
            ]

You don't necessarily need to store or remember the value ids as the inventory system will tie them together.

One additional note here though. If you want to add more possible volume options, you have to add them as new products in the product array. You can't pass multiple "values" in the array.