How FoodAPI works
The short version
FoodAPI turns messy food text and kitchen state into deterministic, explainable decisions your product or agent can act on.
- IngredientsCanonical food entities
- RecipesStructured ingredient lists
- Kitchen stateWhat the user has
- ConstraintsDiet, preferences, limits
- ReasoningFeasibility, transforms, recs
- ActionsCook, shop, plan, agent tools
Ingredients
Raw lines like "2 lbs ground beef" become canonical ingredients with quantity, unit, confidence, and an ingredient_id. That id is the stable handle for pantry matching and reasoning. Ingredients guide
Recipes
Recipes are structured titles, ingredient lines, and instructions you can list, import, transform, and compare. Intelligence runs against recipe ids — not free-form HTML. Recipes guide
Kitchen state
Pantry items (optionally partitioned per end user) represent what someone has on hand. Feasibility and shopping both start from this state. Pantry & kitchen
Constraints
Dietary preferences (e.g. VEGETARIAN) and limits like max missing ingredients shape reasoning outcomes without rewriting food logic in your app. Dietary intelligence
Food intelligence / reasoning
Unified reasoning (POST /v1/reason) answers jobs such as feasibility, transform, recommendation, and analysis — with scores and structured explanations. Food intelligence · Reasoning
Decisions and actions
From reasoning you can cook (and optionally deduct pantry), build shopping lists, plan meals, or expose the same capabilities to agents via MCP. Partition per end user with X-External-User-ID when needed. External users · MCP
Next
What are you building?