I added a modifier to an item and, in the custom modifier configuration, enabled “Require a selection”. Currently, when querying this item via the Square Catalog API, I am inspecting the modifier_list_info object but cannot find a field corresponding to “Require a selection”.
Could you clarify which field in the modifier_list_info or related Catalog objects represents the “Require a selection” setting? How can I programmatically retrieve this property using the Catalog API?
I’m Square Dev AI, here to help answer your question!
Based on the information you’ve provided, the following documentation will help answer your question:
If this documentation helped you find a solution, please check the box indicating that this reply solves the problem.
Otherwise one of our Developer Advocates will provide additional assistance shortly.
Could you clarify which field in the modifier_list_info or related Catalog objects represents the “Require a selection” setting? How can I programmatically retrieve this property using the Catalog API?
An example data model for list-based modifiers is shown in the following UpsertCatalogObject request. The request creates a latte catalog item with small, medium, and large size variations and three modifier lists:
A milk modifier list that:
Sets whole milk as the default milk type ("on_by_default": true).
Requires one selection ("min_selected_modifiers": 1, "max_selected_modifiers": 1).
Prohibits selecting more than one milk type ("allow_quantities": false).
Adds a $1 charge for non-dairy milk.
An espresso shot modifier list that:
Makes extra shots optional ("min_selected_modifiers": 0).
Allows multiple extra shots ("allow_quantities": true).
Allows up to four extra shots ("max_selected_modifiers": 4).
A flavor shot modifier list that:
Makes flavored syrup optional ("min_selected_modifiers": 0).
Allows for multiple flavor types ("allow_quantities": true).
Allows up to six extra shots ("max_selected_modifiers": 6).
Thank you for your earlier reply and for the effort your team has put into improving the handling of min_selected_modifiers and max_selected_modifiers.
However, I’ve noticed a potential issue:
When a new modifier is associated with an item, both min_selected_modifiers and max_selected_modifiers are initialized with the default value -1, which appears to be incorrect.
In the example I provided earlier, the previously incorrect data for these fields was not automatically corrected by Square’s system. Instead, the values only became accurate after I manually re-edited the modifier in the Dashboard.、
Is the -1 initialization the intended default behavior, or is it a bug?
Should developers expect to manually trigger a correction (e.g., via Dashboard edit) to update these values, or will Square provide a mechanism to automatically fix historical data?
If this is known behavior, is there a recommended best practice to ensure accurate values when programmatically creating or updating modifiers?
Thanks again for your support. I look forward to your clarification.
Thank you for your previous response. I understand that -1 is the default value for min_selected_modifiers and max_selected_modifiers.
However, in the two cases I mentioned earlier, I noticed a difference:
In the Square Dashboard, the option “Require a selection” was checked.
But in the API response, both min_selected_modifiers and max_selected_modifiers were still set to -1.
Could you please clarify whether this is the expected behavior?
If not, should we rely on the Dashboard display or the API values when determining whether a modifier selection is required?
Thank you for your response, and I’d like to further inquire:
Has the Square team considered implementing a “what you see is what you get” approach? Specifically:
If “Require a selection” is checked in the Dashboard, then min_selected_modifiers should always be set to 1, rather than sometimes defaulting to -1.
If “Require a selection” is not checked in the Dashboard, then min_selected_modifiers should always be set to 0, rather than sometimes defaulting to -1.
Would the team consider aligning the API behavior with what is shown in the Dashboard to avoid these inconsistencies?