\n\nWhich looks nice, and is copyable in the left-hand side, however the right hand side syas [object Obvject] etc...\n\n---------------\n\nWhen specifying strings of json as the filters like this\n\n```\n 'filter': [\n '{\"limit\":10,\"order\":[\"timestamp DESC\"]}',\n '{\"where\":{\"timestamp\":{\"between\":[\"2024-12-01T00:00:00.000Z\",\"2024-12-01T23:59:59.999Z\"]}},\"order\":[\"timestamp DESC\"]}',\n '{\"where\":{\"correlationId\":\"abc123\"}}',\n ],\n```\n\nWe get an ugly left-hand side with escaping, and a nice right-hand side placeholder (no extra escaping)\n\n\u003Cimg width=\"1509\" height=\"220\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/a411efc1-f555-4d69-abb3-0dab9ee25450\" />\n\nUltimately in one of these cases, I would like the left-hand side to have a copyable string without escaping of \", and in the right-hand side it still be shown nicely in the placeholder.",[],301,"enzonotario","vitepress-openapi","open","Consistently handle example json escaping","2025-08-28T15:58:55Z","https://github.com/enzonotario/vitepress-openapi/issues/301",0.73333657,{"description":3180,"labels":3181,"number":3182,"owner":3172,"repository":3173,"state":3183,"title":3184,"updated_at":3185,"url":3186,"score":3187},"### Current behavior\n\nGiven this schema:\n```yaml\nopenapi: 3.1.0\ninfo: \n title: test\n version: '0.1'\npaths:\n /test:\n get:\n parameters:\n - in: query\n name: code\n examples:\n name_1:\n value: parameter_value_1\n name_2:\n value: parameter_value_1\n schema:\n type: string\n examples: \n - schema_value_1\n - schema_value_2\n```\n\nThe ui shows `schema_value_1` prefilled for `code` parameter which is incorrect.\n\n### Desired behavior\n\nFor GUI openapi tools `examples` from parameter object itself should be used.\nSo prefilled value should be `parameter_value_1` and not `schema_value_1`\n\nhttps://editor-next.swagger.io also uses examples from parameter object. OpenAPI specification itself does not mention `examples` under `schema` field since it is json-schema field and not OpenAPI specific field.",[],298,"closed","`examples` field is not populated from parameter object","2025-08-27T11:00:31Z","https://github.com/enzonotario/vitepress-openapi/issues/298",0.71139795,{"description":3189,"labels":3190,"number":3194,"owner":3172,"repository":3173,"state":3183,"title":3195,"updated_at":3196,"url":3197,"score":3198},"The generated example code looks like this...\n\n```\ncurl 'https://api.foo/v2/devices/%7Bid%7D/tags' \\\n --header 'Authorization: xxx'\n```\n\nHowever really in the UI it would be nicer to look like\n\n```\ncurl 'https://api.foo/v2/devices/{id}/tags' \\\n --header 'Authorization: xxx'\n```",[3191],{"name":3192,"color":3193},"enhancement","a2eeef",223,"Ugly display of { and } in example code","2025-05-18T01:28:54Z","https://github.com/enzonotario/vitepress-openapi/issues/223",0.7738515,{"description":3200,"labels":3201,"number":3202,"owner":3172,"repository":3173,"state":3183,"title":3203,"updated_at":3204,"url":3205,"score":3206},"### Current behavior\n\nMy security scheme is as follows:\n`\"securitySchemes\": {\n \"APIKeyQuery\": {\n \"type\": \"apiKey\",\n \"in\": \"query\",\n \"name\": \"api_key\"\n }`\n\nWhen clicking \"Try it out\", the browser sends:\n```\nGET /api/endpoint\nHeaders: Api_key: example_key\n```\n\n### Desired behavior\n\n`GET /api/endpoint?api_key=example_key`\n\n### Steps to reproduce\n**Environment:**\n- vitepress-openapi@0.1.7\n- \"vitepress\": \"^1.6.3\"\n- browser: any\n\nadd `\"securitySchemes\": {\n \"APIKeyQuery\": {\n \"type\": \"apiKey\",\n \"in\": \"query\",\n \"name\": \"api_key\"\n }` to your openapi.json\nand see that it goes to headers instead of query\n\n### Logs and Error Messages\n\nThis causes API calls to fail since our server expects the API key as a query parameter, making the interactive documentation unusable.\n\n### Other Information\n\nCan you please fix this?",[],294,"API key query parameters sent as headers instead","2025-08-13T01:15:02Z","https://github.com/enzonotario/vitepress-openapi/issues/294",0.7807923,{"description":3208,"labels":3209,"number":3211,"owner":3172,"repository":3173,"state":3183,"title":3212,"updated_at":3213,"url":3214,"score":3215},"Follow on to https://github.com/enzonotario/vitepress-theme-openapi/issues/10\r\n\r\nIt would be great to allow trying out requests that have a body required.\r\n\r\nProbably a first version of this would just provide a single text input box for the whole \"body\" to be provided.\r\n\r\nUsers could then easily copy and paste the example (probably json) body, and modify it",[3210],{"name":3192,"color":3193},42,"Support body for \"try it out\"","2024-09-24T05:03:33Z","https://github.com/enzonotario/vitepress-openapi/issues/42",0.7818991,{"description":3217,"labels":3218,"number":3223,"owner":3172,"repository":3173,"state":3183,"title":3224,"updated_at":3225,"url":3226,"score":3227},"### What would you like?\n\nRight now It generate such page \r\n\r\n\r\nwould like to remove Default on the side and move the table of content to the left\r\n\r\nOr alternatively, if I could change the name and add a description so the left do not feel emptu\n\n### Why is this needed?\n\n_No response_\n\n### How could it be implemented?\n\n_No response_\n\n### Other information\n\n_No response_",[3219,3220],{"name":3192,"color":3193},{"name":3221,"color":3222},"question","d876e3",109,"Any way to remove default or change the name and add description","2024-11-03T03:36:50Z","https://github.com/enzonotario/vitepress-openapi/issues/109",0.7943328,{"description":3229,"labels":3230,"number":3231,"owner":3172,"repository":3173,"state":3183,"title":3232,"updated_at":3233,"url":3234,"score":3235},"Hi! I was working on my current project, where I have a schema that produces this UI:\n\nhttps://github.com/user-attachments/assets/21f90ff1-fb58-4aff-86e5-249e453c829f\n\nThis little screencast aims to show that it's a bit non-obvious - especially for people who are just starting to explore the site with the spec and don't know how the UI works - that object properties are there. Long description with some markdown/emojis makes it seem like the description is all that exists under this property.\n\nIn contrast, when there's no description, it's pretty obvious that the properties are expandable:\n\n\u003Cimg width=\"390\" height=\"113\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/5b945a5a-e471-44b3-8f18-0e0219c8caa0\" />\n\nBut in the case of a rich description - which is visible by default and draws attention away from the relatively small \"expand\" button icon on the top - a user who reads the description might reasonably assume that it's the only content. They may not think, \"Hmm, I read the description, but there must be properties - let me look for some element that will let me show them!\"\n\n## Suggestions:\n\n### Option 1:\n\nHide descriptions for objects when in Collapsed state, show only when Expanded:\n\nhttps://github.com/user-attachments/assets/40ead49f-6023-4cbb-9a7b-8e5a5c96b952\n\n### Option 2:\n\nShow a small hint after the description, like a verbose \"Expand\" text button or a similar UI element (only shown when it's an array/object and has a description):\n\nhttps://github.com/user-attachments/assets/c8a31a05-6b54-400d-84a9-b126b9762b1e\n\n---\n\nLet me know what you think, @enzonotario! Do you like any of the proposed options, or do you have some other idea of how to address this?",[],271,"[Discussion] When an object has a description, it's not obvious that its properties are expandable","2025-07-21T01:18:22Z","https://github.com/enzonotario/vitepress-openapi/issues/271",0.80148774,{"description":3237,"labels":3238,"number":3242,"owner":3172,"repository":3173,"state":3183,"title":3243,"updated_at":3244,"url":3245,"score":3246},"### Current behavior\n\n\n\n### Desired behavior\n\nEither the text should wrap, or just be displayed in a better way\n\n### Reproduction\n\n_No response_\n\n### Steps to reproduce\n\n```\n \"securitySchemes\": {\n \"ApiKeyAuth\": {\n \"in\": \"header\",\n \"name\": \"Authorization\",\n \"type\": \"apiKey\",\n\"description\": \"API Key for authentication. Retrieval from either API version login routes, or other authentication token type. See \u003Ca href='/apis/authentication'>Authentication\u003C/a> for more details.\",\n\"example\": \"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOjEsImlhdCI6MTY3Mjc2NjAyOCwiZXhwIjoxNjc0NDk0MDI4fQ.kCak9sLJr74frSRVQp0_27BY4iBCgQSmoT3vQVWKzJg\"\n }\n }\n```\n\n### Logs and Error Messages\n\n_No response_\n\n### Other Information\n\n_No response_",[3239],{"name":3240,"color":3241},"bug","d73a4a",236,"Long Authorization example doesnt display nicely","2025-06-22T12:55:43Z","https://github.com/enzonotario/vitepress-openapi/issues/236",0.8060854,{"description":3248,"labels":3249,"number":3250,"owner":3172,"repository":3173,"state":3183,"title":3251,"updated_at":3252,"url":3253,"score":3254},"I believe spec such as this is valid and OK.\n\nBasically having a schema object, that has a property of type string, and then using oneOf to be abe to define extra information about the strings.\n\n```\n \"notificationTrigger\": {\n \"properties\": {\n \"name\": {\n \"type\": \"string\"\n },\n \"type\": {\n \"type\": \"string\",\n \"oneOf\": [\n { \"const\": \"lowBat\", \"title\": \"Low Battery\", \"description\": \"Triggered when battery level is low.\" },\n { \"const\": \"button\", \"title\": \"Button Press\", \"description\": \"Triggered on a button press.\" },\n \n```\n\nI believe a relevant link from the spec would be https://spec.openapis.org/oas/v3.1.1.html#model-with-annotated-enumeration\n\nHowever the components currently render this incorrectly.\n\n\u003Cimg width=\"670\" height=\"396\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/267cff6d-9c0a-4bd7-8a8e-734588fb775b\" />",[],288,"Support rendering model-with-annotated-enumeration in Request Body schema","2025-08-11T22:29:43Z","https://github.com/enzonotario/vitepress-openapi/issues/288",0.80945057,{"description":3256,"labels":3257,"number":3259,"owner":3172,"repository":3173,"state":3183,"title":3260,"updated_at":3261,"url":3262,"score":3263},"### What would you like?\n\nI wonder if it is possible to implement path based sidebar. For example, we have\r\n\r\n```\r\n/api/v1/products CRUD\r\n/api/v1/orders CRUD\r\n```\r\n\r\nSidebar would look like\r\n\r\n```\r\n/api/v1\r\n ├ products\r\n | ├ PUT\r\n | ├ GET\r\n | ├ POST\r\n | └ DELETE\r\n └ orders\r\n ├ PUT\r\n ├ GET\r\n ├ POST\r\n └ DELETE\r\n```\r\n\r\n**Note**: empty folders are collapsed\r\n\n\n### Why is this needed?\n\nI want to use more than one tag per endpoint. But in this case sidebar looks strange. Maybe there is a way to organize sidebar better even if there are multiple tags...\n\n### How could it be implemented?\n\n_No response_\n\n### Other information\n\n_No response_",[3258],{"name":3192,"color":3193},119,"Path based sidebar","2024-12-12T03:25:21Z","https://github.com/enzonotario/vitepress-openapi/issues/119",0.8099664,["Reactive",3265],{},["Set"],["ShallowReactive",3268],{"$fTRc1wZytZ_XrK4EfJfei_Sz-An4H4Yy6syhVxH_PVJc":-1,"$fwn1v7wrF4gLDIinn_5Ez2jweFkm9UI-EJh0CnNcpogY":-1},"/enzonotario/vitepress-openapi/221"]