Design your modifier tree with a maximum of two levels of nesting for broad channel compatibility; avoid going deeper unless all target channels explicitly support deeper nesting
Represent each level as a ModifierGroup containing Modifier items; a Modifier that itself has choices should reference a child ModifierGroup by ID — never create circular references between groups
Assign unique GUIDs or PLU codes to every item, modifier, and modifier group; reusing the same identifier across different entities causes platform-side mapping failures
Store your internal POS identifiers in the custom_integration_attributes or equivalent externalId field so inbound orders can be reverse-mapped to your POS data model
Test the full nesting tree against each target platform's sandbox menu validator; some platforms (such as DoorDash Drive) reject more than two nesting levels
Document which channels support nested modifiers and at what depth; maintain a channel capability matrix to gate which menu models are pushed to which channels
Known gotchas
Not all delivery platforms support nested modifiers; pushing a deeply nested tree to an unsupported channel either silently flattens the structure or returns a validation error — test on each channel independently
Most platforms cap nesting at 2 to 5 levels, but the practical limit for broad compatibility is 2 levels; deeper nesting should be used only when all target channels are confirmed to support it
Circular modifier references (Group A references Modifier B which references Group A) will cause infinite loops or stack overflows in menu parsers; validate your data model before submission
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp