Portal
SandboxAPI v1Not signed inExternal user: —

How FoodAPI works

A 3–5 minute mental model — what FoodAPI knows, and how the pieces connect.

The short version

FoodAPI turns messy food text and kitchen state into deterministic, explainable decisions your product or agent can act on.

  1. Ingredients
    Canonical food entities
  2. Recipes
    Structured ingredient lists
  3. Kitchen state
    What the user has
  4. Constraints
    Diet, preferences, limits
  5. Reasoning
    Feasibility, transforms, recs
  6. Actions
    Cook, 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?