Woocommerce REST API display attributes meta_data as slugs - woocommerce-rest-api

Question

I rely on the Woocommerce REST API for a couple different purposes—one is through the shipping platform ShippingEasy and the other is a custom solution to get order information into a google spreadsheet. When retrieving the order information, I have noticed that variable product attributes are coming over as the slugs and not as the case sensitive names.
To make sure there were no bugs or conflicting plugins I performed a clean install, added a couple test products, then pulled the orders using postman via the API. Sure enough Woocommerce serves the slug as the value instead of the name. Here is a small sampling of what is returned from the GET
"line_items": [
{
"id": 3,
"name": "Test Product - Black, Small",
"product_id": 26,
"variation_id": 29,
"quantity": 1,
"tax_class": "",
"subtotal": "6.00",
"subtotal_tax": "0.00",
"total": "6.00",
"total_tax": "0.00",
"taxes": [],
"meta_data": [
{
"id": 29,
"key": "pa_color",
"value": "color-black"
},
{
"id": 30,
"key": "pa_size",
"value": "size-small"
},
{
"id": 31,
"key": "Clip ($5.00)",
"value": "Upgrade"
}
],
"sku": "TEST",
"price": 6
}
],
As you can see, under "meta_data", "key" (the attribute name) is showing the slug and "value" (selected attribute term) is also showing the slug. You may note "id" 29 and 30 are both global attributes, so it is appending the pa_ value to the "key" as well. What is interesting is that if you create the attribute locally (within the product listing), the GET shows the "meta_data" "key" as the slug, but the "value" will show as the case sensitive name. You may note that "id" 31 is displaying both the "value" and "key" with the case sensitive names—these are coming from the Add-ons plugin.
It seems that the meta_data "key" and "value" should be able to display as the case sensitive name. Is it possible this could be resolved using a function within functions.php?

Answer 1

It now looks like the API provides display_key and display_value within the meta_data, which returns the name instead of the slug for each. Oddly enough this is not yet in the API documentation and must be a recent addition, which I stumbled across from testing a random GET request.