Kitchen invites
Share one kitchen (household) with a spouse or family member. Invite links do not send email. Copy the URL and send it yourself.
People (dietary profiles such as Parent A or Child B) stay separate from kitchen members. A kitchen member is a signed-in user who can see the same recipes, plans, and people.
Who can do what
| Action | Owner | Admin | Member | Viewer |
|---|---|---|---|---|
| Create or revoke invite links | Yes | Yes | No | No |
| Change a member role | Yes | No | No | No |
| Remove another member | Yes | No | No | No |
| Leave the kitchen | Yes, unless last owner | Yes | Yes | Yes |
Invite roles are admin, member (default), or viewer. You cannot grant owner through a link. The last owner cannot leave or be demoted.
Create a link
- Open Settings
- Create an invite with a role and expiry (1-30 days, default 7)
- Copy the URL (
/invite/<token>)
Pending links stay listed until they expire or you revoke them. A link can be used by more than one person until then.
Open a link
- Signed out: sign up or sign in through Clerk, then you land in the inviting kitchen
- Signed in: accept the invite and switch to that kitchen
- A brand-new user does not get an extra empty kitchen
If you already belong to more than one kitchen, OvenLovin keeps the last kitchen you selected. After you accept an invite, that kitchen becomes active. Settings includes a kitchen switcher when you have more than one.
REST
Authenticated, scoped to the active kitchen:
GET /api/v1/households/mine- signed-in users see every kitchen they belong to, each withactive. An API key is read-only and returns only its own kitchen withactive: true.POST /api/v1/households/select- signed-in users only. An API key cannot switch kitchens.GET /api/v1/households/membersPATCH /api/v1/households/members/{userId}(owner)DELETE /api/v1/households/members/{userId}(owner)POST /api/v1/households/leaveGET /api/v1/households/invites(owner or admin)POST /api/v1/households/invites(owner or admin)DELETE /api/v1/households/invites/{id}(owner or admin)
Public / accept:
GET /api/v1/invites/{token}(no auth)POST /api/v1/invites/{token}/accept- signed-in person only. An API key cannot join another kitchen; the problem detail names the/invite/{token}link a person must open.
MCP
manage_kitchen_invites-list,create,revokemanage_kitchen_members-list,update_role,remove,leave
API keys are household-scoped. They may list, create, and revoke invite links for the kitchen they belong to (same as MCP manage_kitchen_invites). GET /api/v1/households/mine works for an API key (read-only, that kitchen, active: true). They cannot accept an invite, switch kitchens, leave, or change members: those need a signed-in user. If an API key calls POST /api/v1/invites/{token}/accept, the problem response tells a signed-in person to open the invite link. Share the returned path; the server does not send email.