Add my recipes to API

[daniele2209]

Please add "last cooked" to the API.

[miaucl]

Hey, if you want to help and accelerate it you could try to find the necessary requests needed for it. What do you say?

[FezVrasta]

if you want to help and accelerate it you could try to find the necessary requests needed for it

Found them — the "last cooked" list is served by the organize service, which already publishes the rels in its own .well-known/home, so it needs no new discovery mechanism:

rel	href
organize:api-cooking-history	https://cookidoo.de/organize/{lang}/api/cooking-history
organize:api-cooking-history-multiple	https://cookidoo.de/organize/{lang}/api/cooking-history/multiple

GET /organize/{language}/api/cooking-history
accept: application/vnd.vorwerk.organize.cooking-history.mobile+json
authorization: Bearer <token>

{"userId":"…","entries":[
  {"details":{"timestamp":"2026-09-05T05:31:47.529Z"},
   "recipe":{"id":"r59322","title":"…","totalTime":"5100.0","type":"VORWERK",
             "locale":"","assets":{"images":{"square":"…","portrait":"…","landscape":"…"}}}}
]}

Things worth knowing, all verified against the live API:

• No pagination. ?page= and ?limit= are accepted but ignored — the whole history arrives in one response.
• Newest cooked first.
• totalTime is a stringified float of seconds ("5100.0"), not the plain int the planning endpoints return.
• Content negotiation: anything else 406s with Acceptable representations: [application/vnd.vorwerk.organize.cooking-history.mobile+json, application/json]. The application/json variant returns the same entries plus legacy image fields.
• OPTIONS reports Allow: POST,GET,HEAD,OPTIONS on cooking-history and Allow: POST,OPTIONS on cooking-history/multiple — so recording a cook is presumably a POST, though I didn't try it since that writes to a real account's history.

Implemented the read path in #265 as get_cooking_history(), with unit tests and a smoke test.