Retrieving "Require a Selection" Attribute from CatalogModifierList via Square Catalog API

Dear Square Support Team,

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?

Item ID: U53FTRPSGE4RVWH6EO2KUOUS

Modifier List ID: QFT4QWKIG5PX5JRG4A7ZSFCU

Thank you for your guidance.

Best regards,

Murphy

:waving_hand: 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:

Additional Documentation

Monitor Sold-out Item Variations or Modifiers
Add Custom Attributes
Add a Catalog Item

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.

Hi Square Team:

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?

Hi Square Team:

Could you please help confirm this?

What version of the API are you using? :slight_smile:

The API version is “2025-05-21“.

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:

  1. 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.
  1. 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).
  1. 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). :slight_smile:

Hi Square Team,

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.

Item ID: U53FTRPSGE4RVWH6EO2KUOUS

Modifier List ID: G4ZKG3XA5HNCVAPLFRRPMBKN

  • 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.、

Item ID: U53FTRPSGE4RVWH6EO2KUOUS

Modifier List ID: QFT4QWKIG5PX5JRG4A7ZSFCU

Could you please help clarify:

  1. Is the -1 initialization the intended default behavior, or is it a bug?

  2. 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?

  3. 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.

Best regards,

Murphy

With modifiers -1 is a default and no other action is needed. :slight_smile:

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 help!

Best regards,

Yes, that is expected for required selection. :slight_smile:

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?

We’re constantly working to improve our features based on feedback like this, so I’ll be sure to share your request to the API product team. :slight_smile:

Thank you for your response.

Hi Bryan,

Thank you for looking into this. It seems the issue is still occurring — could you please let me know if there have been any updates or progress?

Thank you very much for your time and assistance.

Best regards,

Murphy

This is the expected behavior and there isn’t any current work to change this. :slight_smile: