Coffee API

• Get a drinkLook up one drink and get its description, what goes into it, and a photo. Pick it from the list, or pass a name or a drink id in from an earlier step: an id costs one small request, and a name is matched against the menu, so 'cold brew' finds Cold Brew and a name that fits two drinks comes back saying which rather than guessing between them.
• Find drinksBrowse the whole menu, or just the part of it you want: search the names, recipes and descriptions for a word, keep only the coffees or only the teas, only the ones served over ice, only the ones containing particular ingredients, and order what is left. The service offers no search, no filter and no ordering that reaches across both of its lists, so both are read once and merged here, which is what lets all of that be one step. The number of drinks matching is always reported, however many are returned.
• Get a random drinkPick one drink at random (the answer to 'what should I order?') from the whole menu or from a corner of it. Different every call. Set a seed when two runs have to agree instead. For a pick that stays the same all day, use Get the drink of the day.
• Get the drink of the dayPick one drink for a day and keep picking that same drink all day. A random pick gives a different one on every call, so a daily workflow that retries, or that two people run an hour apart, posts two different drinks for the one day. This one is fixed by the date: the same date always gives the same drink, and tomorrow gives a different one. Add a seed of your own to have two workspaces post different drinks on the same day.
• List ingredientsList everything the menu is made of, with the drinks that use each thing and whether every one of them treats it as optional. The service publishes recipes but no ingredient list, so this is gathered from the menu: it is what a café would order, or what a 'can we make this?' step checks against. Sugar and Sugar* are counted as the one ingredient they are.
• Check service statusCheck whether the Coffee API is answering, how quickly, and how much of the rate limit is left. This is the one action that reports a problem as a value instead of failing the step, so a workflow can decide what to do about it. Being throttled is reported separately from being down.

No actions match that.