In the preceding sections of this Open API Specification document the Order API component and the Menu API component are described. Within the Order API Attributes chart you will find a second-level deep “modifiers” array (i.e. Order -> Items array -> Item object(s) -> Modifiers array -> Modifier object(s) -> Modifiers array -> Modifier object(s) (blank)) annotated with the text: “we allow for nested modifiers, but may require additional work with you to get this working”. See screenshot of the same here:

Typically – that second-level deep Modifiers array is going to be empty – or omitted – unless we make the deliberate decision to enable nested Modifiers. This section is intended to provide further clarification on how nested modifiers function when they are enabled for ordering platforms.

Order API example:

The Order API Attributes chart from the preceding section already illustrates that non-standard second-level deep nested Modifier situation:

Order -> Items array -> Item object(s) -> Modifiers array -> Modifier object(s) -> Modifiers array -> Modifier object(s)

Of course, you’ll need to imagine that the blank spot in the chart for that second-level deep Modifier object is actually populated with an identical set of information as the first-level deep Modifier object. For Order API - if we’ve enabled nested Modifiers for a location – and if a given Item has nested Modifiers, we just repeat those last 2 elements, as many times as needed: Modifiers array -> Modifier object(s). Typically, the final Modifier object in the chain will be sent with an empty Modifiers array – but it’s also permissible to just omit it.

In this gist you will find an example Order API order packet submitted to 1 of our Lab locations that is already enabled for nested Modifiers. The example of nesting Modifiers in that gist can be described thusly: an “All-American Cheeseburger” Menu Item has an “American” cheese Modifier object, also a "Regular French Fries" Modifier object. The "Regular French Fries" Modifier object has 2 nested Modifier objects: “Bacon” and “Chili”.

Menu API example:

The Menu API attributes chart from the preceding section illustrates the hierarchy of Menu API response object elements thusly:

Menus array -> Menu object(s) -> Sections array -> Section object(s) -> Items array -> Item object(s) -> Modifier Groups array -> Modifier Group object(s) -> Modifiers array -> Modifier object(s)

If we’ve enabled nested Modifiers for a location – and if a given Item has nested Modifiers – we just repeat those last 4 elements, as many times as needed: -> Modifier Groups array -> Modifier Group object(s) -> Modifiers array -> Modifier object(s)

So, a nested Modifier hierarchy with 1 non-standard additional level of nesting is illustrated thusly:

Menus array -> Menu object(s) -> Sections array -> Section object(s) -> Items array -> Item object(s) -> Modifier Groups array -> Modifier Group object(s) -> Modifiers array -> Modifier object(s) -> Modifier Groups array -> Modifier Group object(s) -> Modifiers array -> Modifier object(s)

In this gist you will find an example Item object (sans some superfluous Modifier Groups that we excised) from a Menu API response for 1 of our Lab locations that is already enabled for nested Modifiers. The first example of nesting Modifiers in that gist can be described thusly: a “Traditional Wings” Menu Item has a "Pick One" Modifier Group, which has a "6 Traditional Wings" Modifier object, which has a "Signature Sauce" Modifier Group, which has a "Lemon Pepper (Dry Seasoning)" Modifier object.

What’s Next

What’s Next