Update: The frontend is already implemented.
The only change required will be the addition on OpenAPI in ImportFormat enum and adding the parser code.

OPENAPI specification document contains multiple endpoints and these endpoints branched into folders based on tags and into sub-folders based on /paths
The POSTMAN implementation creates a separate collection on importing openapi file and maintains branching based on tags and endpoints.
But I'm not sure if APIDASH has nested collections.
Rightnow, I'm implementing the parser using DART:CONVERT package.
The basic implementation will add all the endpoints by parsing them into HttpRequestModel
Can I proceed with this approach?

@sajid-31 You can use this package to parse the OpenAPI spec file - https://pub.dev/packages/openapi_spec
Since OpenAPI spec is usually a dump of all the endpoints, once you have the parsed results, you should focus on allowing user to select the endpoints they want to include and add request models to the collections for the selected endpoints.

There is no documentation for openapi_spec. I'm not sure how to implement using this package.
Can you provide a resource which might help me understand this package.
Or should I look for alternatives?

https://pub.dev/documentation/openapi_spec/latest/openapi_spec/

Query parameters can be added directly to the request model for each request endpoint.
How should path parameters be handled?
Since these can be accessed through environment variables, is it better to create a new environment for an OPENAPI JSON/YAML file upload and add the path parameters as variables, or should they be added to the global variables?

@sajid-31 There is no need to create a new environment. You can add path parameters enclosed as{{param}} in the URL itself. It will get highlighted in red and user can create the requisite environment variable or replace it with a hardcoded string as per personal preference.

@ashitaprasad , I will work on this just few question for clarification, and my approach being by adding OpenAPI to our ImportFormat enum and building a parser with the openapi_spec package. Where I will extract endpoints, parameters, and examples from JSON/YAML specifications, then let users select which endpoints they want to add to their API Dash collection. I'll convert selected endpoints to RequestModel objects, handling path parameters, query parameters, and headers appropriately.

• Where in the existing UI should I integrate the OpenAPI import option, and which component handles the current import functionality?

• Will the entire implementation be client-side in Flutter, or should some parsing logic be handled server-side, large OpenAPI specifications that might impact Flutter's performance ?

I'd like to know if anyone has previously started work on this feature or if I need to build it from scratch, As as you mentioned UI is completed for these right?

@ashitaprasad, I successfully set up the application locally and explored it. If you can answer my query, I can kickstart the issue. Also, while using the application, I noticed how it allows importing from a Postman collection. Similarly, in the same kind of UI, we would need to add OpenAPI specs, right, to conclude?

@ashitaprasad , I will work on this just few question for clarification, and my approach being by adding OpenAPI to our ImportFormat enum and building a parser with the openapi_spec package. Where I will extract endpoints, parameters, and examples from JSON/YAML specifications, then let users select which endpoints they want to add to their API Dash collection. I'll convert selected endpoints to RequestModel objects, handling path parameters, query parameters, and headers appropriately.

• Where in the existing UI should I integrate the OpenAPI import option, and which component handles the current import functionality?
• Will the entire implementation be client-side in Flutter, or should some parsing logic be handled server-side, large OpenAPI specifications that might impact Flutter's performance ?

I'd like to know if anyone has previously started work on this feature or if I need to build it from scratch, As as you mentioned UI is completed for these right?

@akshayw1 Figuring out answers to these questions are part of the task.

@ashitaprasad, I have everything figured out and can start now. I asked for confirmation earlier, but no worries—I’ll implement the integration similar to what we have for Postman and Insomnia, but for OpenAPI.

@ashitaprasad I have completed work on the issue. Now, I can import OpenAPI JSON or YAML files, select/delete items via a dialog, and import them into the side panel. Below is the demo video of implementation—please review it, and if everything looks good, I'll proceed with the PR.

@akshayw1 You can send across a draft PR.

@akshayw1 You can send across a draft PR.

Okay will do , Just wanted to confirm the flow seems correct right? Will make PR in morning

@ashitaprasad I would appreciate it if you could review the PR. If there are any issues, please let me know, and I'll be happy to address them promptly. It's been open for over 48 hours now.