bug(api): menu item custom_url not persisted via REST API POST

[Vallhalen]

Bug

POST /_emdash/api/menus/:name/items with type: "link" accepts the request (201) but does not persist custom_url or url. The created item always has custom_url: null.

Reproduction

curl -X POST "https://example.com/_emdash/api/menus/primary/items" \
  -H "Authorization: Bearer TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"type":"link","label":"Blog","custom_url":"/blog","sort_order":3}'

Response: 201 Created with "custom_url": null

Also tried "url": "/blog" — same result.

Impact

After upgrading to 0.10.0, our primary and footer menus lost all items (likely due to migration 036_i18n_menus_and_taxonomies). When trying to recreate items via REST API, the URL field is never saved, resulting in all menu links pointing to #.

Workaround

We patched getMenu() output in our layout with a label→URL fallback map:

const menuUrlMap = { 'Blog': '/blog', 'Portfolio': '/portfolio', ... };
function patchMenuUrls(m) {
  return { ...m, items: m.items.map(item => ({
    ...item,
    url: (item.url && item.url !== '#') ? item.url : menuUrlMap[item.label] || '#',
  })) };
}

Environment

• EmDash 0.10.0
• Cloudflare Workers + D1
• Menu items created via REST API (not admin UI)

Additional note

DELETE /_emdash/api/menus/:name/items/:id also doesn't seem to work — returns the 404 page HTML instead of a JSON response.

[Rimander]

Thanks for the detailed report and for sharing the workaround — it helped me confirm both behaviors. Here is what we found while tracing the API flow and what we plan to change.

DELETE /menus/:name/items/:id → 404 HTML

Confirmed. Today the actual route is DELETE /_emdash/api/menus/:name/items?id=<itemId> (query string). There is no [name]/items/[id].ts file, so Astro replies with the SSR 404 page (HTML) instead of a JSON envelope.

This is an inconsistency with the rest of the API. Every other resource uses the path-style [id]:

Resource	DELETE	Style
Content (posts, pages, custom types)	api/content/[collection]/[id].ts	path
Taxonomy terms	api/taxonomies/[name]/terms/[slug].ts	path
Redirects	api/redirects/[id].ts	path
Sections	api/sections/[slug].ts	path
Widget areas	api/widget-areas/[name].ts	path
Menu items (today)	api/menus/[name]/items.ts + ?id=	query (anomaly)

Plan: add api/menus/[name]/items/[id].ts with PUT and DELETE, reusing the current handlers, aligning menus with the rest of the API.

POST …/items with custom_url → 201 but custom_url: null

The end-to-end flow

We walked it step by step:

1. parseBody (packages/core/src/api/parse.ts) does no preprocessing. It hands the raw JSON straight to schema.safeParse(data).
2. The Zod schema (api/schemas/menus.ts) declares customUrl in camelCase:

   createMenuItemBody = z.object({
     customUrl: safeHref.optional(),
     referenceCollection, referenceId, titleAttr, cssClasses,
     parentId, sortOrder, type, label,
   });

   By default, Zod's .object() silently strips unknown keys (.strip()). custom_url, sort_order, or url are dropped without an error.
3. The handler (handleMenuItemCreate) does the camelCase → snake_case mapping manually:

   .values({
     custom_url: input.customUrl ?? null,
     sort_order: sortOrder,
     parent_id: input.parentId ?? null,
     reference_collection: input.referenceCollection ?? null,
     ...
   })

   There is no automatic snake_case → camelCase mapper (not for menus and not for any other endpoint). Every API field is named twice: camelCase on the input side, snake_case on the database column side.

So if customUrl comes in, it gets saved correctly; if custom_url comes in, it falls through the ?? null branch.

Codebase convention

API input: 100% camelCase. It is uniform across every schema (content.ts, redirects.ts, taxonomies, etc.):

// createContentBody (posts, pages, custom types — every collection)
{ data, slug, status, locale,
  translationOf,     // not translation_of
  authorId,          // not author_id
  publishedAt,       // not published_at
  createdAt,         // not created_at
  scheduledAt,       // not scheduled_at
  skipRevision,      // not skip_revision
  bylines, seo: { noIndex, canonical, … } }

Same in redirects: groupName (not group_name); in widgets, comments, taxonomies: same story.

The SQL columns are snake_case (author_id, published_at, custom_url, sort_order), and the API responses mirror those columns because they come from a direct .selectAll() in Kysely. That asymmetry (camel in, snake out) is a minor debt in the API but doesn't affect persistence. The generated OpenAPI (/_emdash/api/openapi.json) is built from the same Zod schemas, so it already documents customUrl as the correct name.

Input/output asymmetry: content hydrates, menus doesn't

There's a difference in how content and menus return the row after INSERT, and I think it deserves an alignment (though it's not a blocker for the bug fix). I noticed it while tracing the flow:

• content has a hydrator that turns the DB row into a ContentItem with camelCase properties. That's why responses from /_emdash/api/content/* look like:

  { "id": "…", "authorId": "…", "publishedAt": "…", "createdAt": "…", "translationGroup": "…" }

• menus returns Selectable<MenuItemTable> directly (the raw Kysely row), so the response comes out in snake_case:

  { "id": "…", "menu_id": "…", "custom_url": "…", "sort_order": 3, "translation_group": "…" }

Stage	content	menus
Input schema	camelCase (publishedAt, authorId)	camelCase (customUrl, sortOrder)
Handler → repo	camelCase	camelCase (input.customUrl)
SQL mapping	manual input.publishedAt → published_at (repositories/content.ts:563-572)	manual input.customUrl → custom_url (handlers/menus.ts:566)
DB column	snake_case	snake_case
Response hydration	yes → camelCase (ContentItem)	no → raw snake_case (MenuItemRow)

What's going to change

• Add .strict() to createMenuItemBody / updateMenuItemBody so that custom_url, url, sort_order, etc. return 400 with Unrecognized key: "custom_url" instead of a silent 201 with null. Fail loud, make the contract obvious.

Example that works today, no patch needed

curl -X POST "https://example.com/_emdash/api/menus/primary/items" \
  -H "Authorization: Bearer TOKEN" \
  -H "Content-Type: application/json" \
  -H "X-EmDash-Request: 1" \
  -d '{
    "type": "custom",
    "label": "Blog",
    "customUrl": "/blog",
    "sortOrder": 3
  }'
# → 201 with custom_url: "/blog"