Pub operators manage rotating food and drink specials once, then publish them to the places patrons already look: the specials page, the menu, and eligible venue displays.
What patrons see
A special can include a title, short description, price, image, and preparation details. The public page separates what is currently offered from an archive of earlier items. Display and menu placements use a shorter presentation suited to their context.
Availability on the website is informational. A product may sell out or change before every screen refreshes; ask a tender when current availability matters.
Operator workflow
- Create or update the special in the protected operator area.
- Add only information and imagery approved for public display.
- Choose when it should be active or associate it with the relevant service period.
- Preview the patron-facing presentation.
- Archive it when it is no longer offered; restore it only after confirming the details are still accurate.
Preparation fields currently appear on the public specials experience and API. Operators should enter only information suitable for patrons and must not use those fields for confidential recipes, supplier details, or private staff notes.
flowchart LR OPERATOR["Operator manages one special"] --> SERVICE["Pub validates and publishes it"] SERVICE --> PAGE["Specials page"] SERVICE --> MENU["Menu summary"] SERVICE --> DISPLAY["Eligible venue display"]
Technical boundary
The public service can return current or archived presentation-ready items, including preparation details entered for the item. Protected editing and change history remain behind Pub authorization. Images are prepared for web and display use before publication; production storage and transformation details are not part of the public contract.
See Public API reference for the public read endpoint.
Related: Venue displays · Admin access