Support intake: submitSupportRequest is unimplemented; the real route (POST /api/webhook/{webhookType}) has no schema

[ritzorama]

Current Behavior

schemas/constructs/v1beta1/support/api.yml declares submitSupportRequest -> POST /api/integrations/support, and typescript/rtk/cloud.ts generates a client for it.

Meshery Cloud does not implement that route. Its router has no /integrations/support handler; the only support intake is the generic authenticated webhook route:

• POST /api/webhook/:webhookType -> handlers.CallWebhook (server/handlers/webhooks.go)
• body: models.SupportPayload = { "memberFormOne": { firstname, lastname, email, subject, message, scope, form } }, decoded with DisallowUnknownFields
• forwarded server-side to the URL in WEBHOOK_HELP_AND_SUPPORT

Both consumers use the webhook route, not the generated operation:

• Layer5 Cloud UI: ui/components/modals/help-and-support-modal.tsx via the hand-authored callWebhook in ui/api/api.ts
• Kanvas: ui/src/rtk-query/support.ts (layer5labs/meshery-extensions), which was just repointed off a browser-side third-party webhook onto POST /api/extensions/api/webhook/support

So the generated submitSupportRequest is a phantom: consuming it 404s every support ticket. It is also a name trap - it reads as the canonical support operation, so the obvious "stop hand-declaring, use the generated client" cleanup is exactly the change that silently breaks support intake.

Desired Behavior

Resolve the divergence in one of two directions, and make the schema match what Cloud actually serves:

1. Schema the real operation. Add callWebhook -> POST /api/webhook/{webhookType} with SupportPayload/MemberFormOne as the request body, so both consumers can drop their hand-declared endpoints. Note the payload's wire names are lowercase (firstname, lastname) because they mirror the downstream form's input names - if the identifier-naming contract requires firstName/lastName, that rename has to be coordinated with the Cloud handler and the downstream intake in the same change.
2. Or implement POST /api/integrations/support in Meshery Cloud (forwarding to the same configured webhook) and migrate both consumers, retiring the webhook route for support.

Either way, whichever operation ends up unimplemented should be removed from the schema rather than left generating a client that cannot work.

Note the two payloads are not equivalent today: SupportRequest is {subject, message, scope} with scope enum Support|Community|Account|Commercial, while MemberFormOne additionally carries firstname/lastname/email/form and an unconstrained scope. The intake needs the requester identity, so a straight swap to SupportRequest would drop it.

Context

Found while routing Kanvas support submissions through Meshery Server (they previously POSTed the signed-in user's name and email from the browser straight to a third-party webhook origin). Kanvas now hand-declares the webhook endpoint with this issue linked at the declaration, per the deliberately-local-endpoint rule.