If a property isn't self-evidently named in the API JSON object, you can usually use your browser devtools to inspect the relevant checkbox/field, where the name/id attribute for that HTML element should indicate the corresponding API property. Generally those names are all consistent among our backend code/DB, the frontend Dashboard UI, and the API, but some in the UI may have a prefix indicating which screen it's on.
E.g., regarding some of the properties you mentioned:
- Let Buyers Edit Price:
variable_pricing
- Bundle Other Products:
needs_multiple
That said, the following properties don't appear reported in the product JSON objects currently, so I'll ask Dev if they can add support for them:
- Let Buyers Edit Quantity:
variable_quantity
- Require Buyer's Shipping Address:
needs_shipping
- Shipping Weight:
item_ounces
- Webhook Integration:
needs_information
- (Let us know if you need any others)
The setting to Send Product Thank-you Email is inferred from the combination of successful_payment_message (Product Thank-you Email Message) and needs_advanced_successful_payment_message (Don't include default greeting and link/code).
When the the former is blank, and the latter is true for items that also have true for any digital-delivery setting (needs_download, needs_redirection, needs_exhaust_password, needs_keygen, or needs_multiple), the product email is disabled; other products only need successful_payment_message blank to disable the message.
However, as neither of those are supported in the API yet, and the successful_payment_message content could contain special chars that need to be sanitized/escaped, I'm suggesting to Dev they just report that as a boolean value (if empty false, else true).
Speaking of, note that some apparent boolean values may actually be quoted strings, whereas true booleans are left unquoted. This is a legacy from our earliest days when our founder hadn't yet realized the value of maintaining consistent strict-typing discipline.
