Status
Public API: not yet exposed. Internal HTTP surface: live at /recipes/*. gRPC layer: recipe.grpc.controller.js.
Planned endpoints
| Method | Planned path | Action | Planned scope |
|---|---|---|---|
GET | /orgs/:o/entities/:e/recipes | List | recipe:read |
GET | /orgs/:o/entities/:e/recipes/:id | Read one | recipe:read |
GET | /orgs/:o/entities/:e/items/:itemId/recipe | Get recipe by output item | recipe:read |
POST | /orgs/:o/entities/:e/recipes | Create | recipe:create |
PUT | /orgs/:o/entities/:e/recipes/:id | Update | recipe:update |
DELETE | /orgs/:o/entities/:e/recipes | Soft-archive (bulk) | recipe:delete |
PUT | /orgs/:o/entities/:e/recipes/restore | Un-archive (bulk) | recipe:update |
When to use Recipe vs BOM
Both model "what goes into making something" but in different domains:
- BOM is for discrete manufacturing — explicit components, fixed quantities, often a single output item per BOM. Used when you assemble units (electronics, machinery, furniture).
- Recipe is for process manufacturing — proportional inputs (often by weight or volume), batch yields, sometimes multiple output items per run. Used when you mix or transform (food, chemicals, pharma).
Many tenants use only one. The internal data models are deliberately separate so that process-industry features (yield variance, batch lot tracking) don't pollute the discrete-BOM shape.