Is there anything wrong with having "one" endpoint to service multiple "types" of requests?

Let's say for example I have some pizza delivery service. Types of things it can do are

• CreateOrder
• CancelOrder
• GetOrderStatus

for example. The API layer of my service might expose these as "separate" endpoints like /order (POST), /order (DELETE), etc. and these are somehow routed to a worker layer that processes the requests.

Is it OK to make the worker receive requests through a single message queue where messages are like

{
    id: "47a4aa26-295c-4163-9701-b6c20863643a",
    type: "order-create",
    payload: {
         size: "xl",
         toppings: ["canadianBacon", "pineapple"]
    }
}

and

{
    id: "4278dd527-6c4f-4bee-b8f6-0871af0b39ce",
    type: "order-cancel",
    payload: {
         orderId: "dff1b7e4-0c07-4327-8590-ac71065f32e5",
         cancellationDate: "Mon Oct 14 2019 09:24:20 GMT-0700 (Pacific Daylight Time)"
    }
}

instead of having every different type of message go to a "separate" queue (or some other type of "separate" abstraction/infrastructure like a topic if using Azure Service Bus).

What I like about this is whenever there's a new type of business capability that I want my pizza delivery service to have, I just define a new type and payload contract and write a new handler, don't need to create any new infrastructure/routing/etc.