Discussion on #5 - Open Responses & Generative UI

[animator]

Open Responses is an open-source specification and ecosystem for building interoperable, multi-provider LLM interfaces inspired by the OpenAI Responses API. It defines a common, vendor-neutral way to describe AI requests and structured response outputs, enabling portability and consistency across AI platforms. Complementing this, Google's A2UI introduces clear guidelines for building Generative UIs, with first-class support available through Flutter's GenUI SDK.

Your task is to understand these specifications and build rich API response UI visualization in API Dash to enable end users to integrate the same in their Flutter Apps and Web Apps.

Tech Stack: React/Node/TypeScript or Dart/Flutter

Please feel free to discuss your ideas/research below.

[Rajaykumar12]

Hi @animator

I'm Ajay, and I'd love to contribute to the "Open Responses & Generative UI" project.

I've been digging into the Open Responses spec and looking at how Flutter's GenUI SDK maps structured data to interactive widgets. Since the end goal is to build a rich UI visualizer in API Dash that devs can drop into their own Flutter and Web apps, I had a quick question about the scope.
Should the initial focus be on building a solid set of default Generative UI components (like tables, lists, or cards) to handle the most common schemas? Or are we leaning more toward a "playground" setup where devs can plug in and test their own custom UI component mappings right inside API Dash?

Best,
Ajay

[animator]

@Rajaykumar12 You can do your research, run API Dash and submit an idea doc as a PR.

[jess-tech-lab]

Hey @animator! 👋 I’m a Computer Science student at UWaterloo with a solid background in Node.js, TypeScript, REST APIs, and building LLM-backed interactive UIs.

I’m really excited about GSoC 2026 Idea #5 — Open Responses & Generative UI. I’ve already set up the API Dash environment on my Mac (navigating through the Xcode/entitlements setup) and have been exploring the codebase. My thinking so far:

• Interoperability: The goal is to make API Dash the "universal viewer" for AI. I plan to build a robust Dart parser for the Open Responses spec. Coming from a TypeScript background, I’m eager to translate the spec’s structured event streaming into Dart types to handle various LLM outputs (Gemini, OpenAI, etc.) consistently.

• Generative UI (A2UI): I want to implement a dedicated "GenUI" tab in the response pane. Using the Flutter GenUI SDK, I’ll map structured JSON components into native, interactive Flutter widgets. I'm particularly interested in implementing progressive rendering so the UI updates in real-time as the LLM streams the A2UI messages.

Since I have experience in Python, I’m also happy to develop local test servers to simulate complex Agentic A2UI responses for robust testing of the frontend implementation. Looking forward to discussing this more! 🚀

[animator]

@jess-tech-lab you can send a idea doc as a PR for review.

[jess-tech-lab]

Hi @animator! Thank you so much for the invitation to submit an idea doc. After reviewing my current commitments and the depth required for a high-quality GSoC proposal, I’ve decided to focus my efforts on a single project this year rather than spreading myself too thin.

I’m still a huge fan of API Dash, so I’ll likely be following the progress from the sidelines and may apply again next year when I can dedicate the necessary time. Good luck to the team and the other applicants!

[Saad-Mallebhari]

@animator
Hi @animator!

I'm a 2nd year IT student with experience in Python, REST APIs, and working with LLM APIs . I'm really interested in contributing to GSoC 2026 Idea #5 - Open Responses & Generative UI.

I've started reading through the Open Responses specification and looking into how structured responses could be mapped into UI components. My initial thought is that starting with a core set of common components (tables, lists, cards, etc.) would make the response visualizer immediately useful, and later expanding to support custom component mappings or plugin-style UI renderers could make API Dash more extensible.

Since the spec focuses on structured outputs across multiple providers, I’m particularly interested in how the parser layer will normalize different response formats before rendering them in the UI.

I'm currently setting up the API Dash environment and exploring the codebase to better understand how responses are handled today.
Looking forward to learning more about the expected architecture and contributing to the discussion!

[animator]

@Saad-Mallebhari you can send a idea doc as a PR for review.

[veyron-kairo]

Hey @animator,

I'm Shridhar! I've been exploring the API Dash codebase for the past few days and this project caught my eye.

I've gone through the Open Responses spec, A2UI docs, and the Flutter GenUI SDK to understand what we're working
with. I also dug into how API Dash currently handles responses — looked at the response body widgets, the previewer,
and the genai package to get a sense of where things would need to change.

From what I understand, the core idea is to make API Dash capable of rendering rich, interactive UI from AI API
responses instead of just showing raw JSON. Here's what I'm thinking so far:

• Parse Open Responses structured outputs into a common format that works across providers
• Detect A2UI payloads in responses and render them as actual Flutter widgets using the GenUI SDK
• Maybe extend DashBot to show these rich UI components in the chat as well

Still reading through the specs more carefully and I might be off on some of this — would love to hear your thoughts
on what you'd want the focus to be on.

I've also raised a small PR (#1279) to get familiar with the contribution workflow.

[animator]

@sridhar-panigrahi you can send a idea doc as a PR for review.

[veyron-kairo]

his @animator , I've send idea doc as pr #1321 , please let me know your thoughts on this !

[Armaansaxena]

Hey @animator I've submitted my idea doc PR for Idea #5 → #1302. I ran the GenUI SDK travel app locally this week, explored the full widget catalog, and built the proposal around real observations.
Also have the full proposal as a Google Doc for easier review → https://docs.google.com/document/d/1QOisUPIgoWRezvdAK4qwyMmTCA4FXt-bfRHYY-MrRDI/edit?usp=sharing
Would love your feedback! 🙏

[Armaansaxena]

Update: Based on the Weekly Connect feedback, I've built a working POC for the parser — normalizes responses from Gemini, OpenAI, Anthropic and Ollama into one common structure. Run it locally here → https://github.com/Armaansaxena/llm-response-parser
Working on updating the idea doc with better pain points and mockups next!

[abhinav29102005]

Hi @animator,
Really interesting challenge. I've been digging into the interoperability side of Open Responses lately and the biggest hurdle I see is definitely the schema mapping.
Since providers like Gemini and OpenAI handle structured tool calls differently, I’m thinking about proposing a normalization layer in Dart. This would basically sit between the raw response and the GenUI SDK so API Dash doesn't need new custom logic every time a model provider updates their spec.
I’ve also been looking through the genai package in the repo. Adding a dedicated GenUIRenderer that follows the A2UI guidelines (specifically the separation of system vs generated UI) seems like it would be a huge win for the DX.
I’m putting these thoughts into an idea doc and should have the PR ready shortly. Quick question before I finish it—do you have a preference for prioritizing the travel or task UI templates from the A2UI spec first?

[VanshKaushal]

Hi everyone @animator 👋

I spent some time exploring the Open Responses specification and Google’s A2UI / GenUI concepts, and I wanted to share a few thoughts on how we could approach building rich API response visualization in API Dash.

The main goal seems to be enabling interoperable AI responses and visualizing them in a way that developers can directly reuse in their Flutter or Web apps.

The Open Responses specification provides a vendor‑neutral format for AI requests and structured responses. A2UI / GenUI focuses on rendering structured AI outputs as dynamic UI components instead of plain text.

Because of this, API Dash could go beyond showing responses as raw JSON or text. It could interpret structured responses and render them as UI components that developers can preview and reuse.

One possible approach is to introduce a response parsing layer. This layer would read the Open Responses JSON schema and detect different response types such as text, markdown, code, tables, charts, or UI blocks. The parser would then convert the raw response into an intermediate UI schema that can be rendered.

After parsing, a UI rendering layer could display the response visually. One option is a React-based renderer that converts the parsed schema into components like TextBlock, CodeBlock, MarkdownRenderer, TableView, ChartComponent, or other interactive UI blocks. Another option is generating a portable UI schema that can also be rendered in Flutter using the GenUI SDK, allowing the same response structure to work across platforms.

Inside API Dash, the response panel could include multiple views. For example, a raw response view for JSON, a rendered UI preview, and possibly generated code previews for Flutter or React. This would allow developers to inspect the response, see how it looks as a UI, and reuse the generated components in their applications.

A typical flow could be: a user sends an AI request in API Dash, the response arrives in the Open Responses format, the parser converts it into a UI schema, and the renderer displays an interactive preview. Developers could then export or reuse the UI structure in their own apps.

Initially, the renderer could support common components such as markdown rendering, syntax highlighted code blocks, tables, charts, cards, and structured layouts. Over time, this could be extended with features like a plugin system for custom components, streaming response visualization, tool-call visualization for AI agents, and exporting reusable UI templates.

I would also like to ask a few questions for discussion. Should the first implementation focus on a React-based renderer inside API Dash, or should we prioritize generating a cross-platform UI schema that works well with Flutter GenUI? Are there example Open Responses schemas that we should use as references for building the renderer? And would it be useful if API Dash could export UI code for Flutter or React directly from the response preview?

I would be happy to prototype a basic response parser and renderer to explore this direction further. Looking forward to feedback.

[animator]

@VanshKaushal You can join our weekly calls to discuss any questions you have.

[aadish-25]

Hi @animator
I’d like to propose some UI improvements for API Dash:

When opening a collection or folder, show its requests and subfolders in the main view (instead of a blank area).
Add a collapsible sidebar for better navigation and workspace management.
Implement right-click context menus for collections, folders, and requests, so users don’t have to use the hamburger menu every time.
These changes would make the app more intuitive and user-friendly, especially for desktop users.
Would love to hear your thoughts and feedback!

[animator]

@aadish-25 Please send proposal doc PR.

[rafiamaqsood]

Hi @animator

I’m a Computer Science student and I’m interested in contributing to GSoC Idea #5 – Open Responses & Generative UI. I’ve been exploring the API Dash repository and was able to run the project locally while looking through how API responses are currently rendered.

From what I understand, the goal of this project is to allow API Dash to visualize structured AI responses instead of only showing raw JSON. The Open Responses specification provides a standardized format for AI outputs, while A2UI / GenUI focuses on converting structured responses into interactive UI components.

One approach I’ve been thinking about is introducing a response parsing layer that detects Open Responses structured outputs and converts them into an intermediate UI schema. This schema could then be mapped to Flutter widgets such as cards, lists, tables, or text blocks.

After parsing, API Dash could include a Generative UI preview panel in the response section. This would allow developers to switch between the raw JSON view and a rendered UI preview generated from the structured response.

Another interesting direction could be supporting progressive UI updates for streaming AI responses, where the UI updates dynamically as structured response events arrive from the model. This could make it easier to visualize agentic workflows or tool-call responses in real time.

For the initial version, supporting a core set of components such as cards, lists, tables, and markdown blocks would make the renderer immediately useful. Later, the architecture could potentially be extended to support custom component mappings or plugin-style UI renderers.

I’m currently continuing to explore the codebase to better understand where response parsing and rendering could integrate into the existing architecture.

One question I had:
Would the preferred direction be to keep the renderer tightly integrated with Flutter widgets inside API Dash, or to define a portable intermediate UI schema that could also be reused by developers in their own Flutter or web applications?

Looking forward to learning more and contributing to the project.

[animator]

@rafiamaqsood Please send proposal doc PR.

[Saidmurotov]

Hi @animator,

Thank you. I will go through the relevant resources, run API Dash locally, and prepare an initial idea document for this project. I’m especially interested in understanding how Open Responses can be integrated into API Dash for Flutter and web apps.

I will share my research and draft idea document soon.

Best,
Sulaymon

[animator]

@Saidmurotov Please send proposal doc PR.

[veyron-kairo]

Hey @animator @ashitaprasad — I've been working on the PoC for the Open Responses & Generative UI idea since my last comment here.

Just pushed it as a draft PR: #1358

What's working so far:

• Auto-detection of Open Responses format responses (checks for object == "response" + output[]) and switches the response pane to a structured card view instead of a raw JSON blob
• Each output item type renders differently — messages as chat bubbles with role labels, reasoning as a collapsible card showing the summary (full trace on tap), function calls with expandable pretty-printed args + status chip, tool results linked to their call_id
• A2UI v0.9 JSONL detection and rendering — parses updateComponents/updateDataModel messages into a component tree and renders it with Text, Button, Card, Row, Column, Image, List etc.
• Token usage bar at the bottom for Open Responses

Fits into the existing pipeline without touching anything outside of ResponseBodyView and ResponseBodySuccess — existing behaviour is completely unchanged.

Still to do: live streaming (building the structured view incrementally from SSE events) and full A2UI data binding reactivity. Those are the meatier parts I'd tackle during the project.

Would love any feedback on the approach or scope. Thanks!

[milanprajapati571]

Hello, @animator Sir

I have been studying the Open Responses & Generative UI idea and going through the specification references mentioned in the discussion thread (#1227). From my understanding, the goal of this project is to enhance API Dash so it can properly interpret and visualise structured AI responses in accordance with the Open Responses specification and the Generative UI guidelines (A2UI/GenUI), rather than just showing raw JSON or text output.

Currently, API Dash displays API responses as plain data, but modern LLM APIs can return structured outputs, tool calls, and UI schemas. The purpose of this project seems to be to parse those responses, determine their type, and render them as rich UI components that can also be reused in Flutter or web apps, following the GenUI guidelines.

My current understanding of the implementation direction is the following:

1. Study the Open Responses specification and define a parser that can identify different response types such as text, structured JSON, tool calls, and UI schema.
2. Implement a response parser layer in API Dash that converts the raw response into a normalised internal format.
3. Add support for Generative UI schema parsing so that UI components described in the response can be rendered dynamically.
4. Build a visualisation layer in API Dash (React / TypeScript) that can render these components in a preview panel.
5. Ensure the rendered structure is compatible with Flutter GenUI / A2UI guidelines so that users can reuse the same response format in Flutter and Web apps.
6. Design the system in a modular way so that new response types or UI components can be added later.

I would like to confirm whether I am on the right track with this understanding.
If possible, please suggest the best starting point in the codebase or any additional resources that I should study to better understand the Open Responses format and the expected UI rendering approach.

I am very interested in working on this idea and would like to start exploring the relevant parts of API Dash to contribute in the right direction.

Thank you.

[milanprajapati571]

Hello @animator, please review my idea and provide feedback if needed, so I can start working on it. I have to draft a final proposal based on the idea and suggestions you provided.

[Sniplyy]

Hi @animator

I have had the chance to research about Open Responses & Generative UI idea and going through the specification references mentioned in the discussion thread (#1227). From my understanding, the goal of this project is to enhance API Dash so it can properly interpret and visualise structured AI responses in accordance with the Open Responses specification and the Generative UI guidelines (A2UI/GenUI), rather than just showing raw JSON.

Currently, API Dash displays API responses as plain data, but modern LLM APIs can return structured outputs, tool calls, and UI schemas. The purpose of this project seems to be to parse those responses, determine their type, and render them as rich UI components that can also be reused in Flutter or web apps, following the GenUI guidelines.

I have developed an interface for the same by integrating Google's A2UI and flutter GenUI repos.

I am still working on the PR yet. As soon as I am done with testing I will send it for review

Thank you

[dhairyajangir]

Hi @animator , I want to work on Idea 5. I have read the Open Responses spec, the A2UI guidelines, and the Flutter GenUI SDK docs, and I have submitted a full idea doc and application as PR #1512.

My approach, which is already documented in that PR, is to build this in four clear layers: an Open Responses parser with fallback handling for unknown item types, a structured card renderer inside the existing response viewer, a streaming-aware state layer for progressive delta updates, and a Generative UI preview surface with explicit MVP component scope and graceful fallback for unsupported payloads. The reason I scoped it this way is that the hard constraint here is not design, it is streaming state correctness and making sure the parser does not break existing response rendering for non-AI payloads.

Two PRs I have open in the repo that are relevant context (POC):

PR #1492 adds application/x-www-form-urlencoded body type support, touching HttpRequestModel, http_service.dart, the form-data editor views, and unit tests in http_request_model_test.dart. I went through the full request pipeline to understand how content types are handled end to end, which is the same path that structured response rendering integrates into.

PR #1499 fixes RenderFlex overflow in the AI Model Selector dialog and extends the Postman v2.1 importer with auth mapping (Bearer, Basic, API Key), urlencoded body import, and collection variable substitution across 8 files with importer and serialization tests.

Both give me working familiarity with the codebase before the proposal period, not after.

I have also built SAKHI, a Flutter app where I converted structured JSON payloads into production UI components. That is directly what the Generative UI layer requires: reliable schema detection, graceful rendering of known component types, and safe fallback for unknown ones.

@ashitaprasad @animator , happy to discuss scope or answer any questions on the approach.

Full proposal and idea doc: #1512

[Syed-Abdullah-G]

@animator @ashitaprasad
I have raised PR for review for the Open Responses & Generative UI idea, let me know if there is any change to be made further.

PR - #1517 (comment)

[HuzaifaFurqan92]

hey @animator

I am a Software Engineering student at NUST with mid-level experience in Flutter and a background in building AI systems (including implementing CNNs from scratch). I am deeply interested in the Open Responses & Generative UI project.

I’ve been studying the A2UI (Agent-to-User Interface) specification and the Flutter GenUI SDK. My focus is on how we can leverage the "A2uiTransportAdapter" to map vendor-neutral Open Responses into interactive components within API Dash. Specifically, I’m interested in:

Schema Mapping: Ensuring consistent rendering across OpenAI, Gemini, and Anthropic via the Open Responses spec.
Component Cataloging: Defining a robust "Catalog Item" set to dynamically render widgets like interactive charts or action buttons.
State Synchronization: Implementing the "Surface Controller" to handle the interaction loop between the user and the AI state.

I am currently setting up the GenUI SDK locally to test mock payloads and plan to submit a small PR (UI improvement or bug fix) to demonstrate my familiarity with the codebase. I look forward to contributing!"

[AashishGupta2007]

Hi, I have been studying the current response preview path in API Dash, especially the JSON preview side, to understand where structured AI response rendering can be introduced without disturbing existing response handling.

My current proposal direction for Idea #5 is intentionally scoped as an MVP:
• detect Open Responses payloads using lightweight schema checks (object == "response" and output[])
• classify a small set of output item types first (message, reasoning, function_call, tool_result)
• render those through semantic cards inside the response pane
• preserve current JSON/raw preview as fallback for unsupported structures

For Generative UI, I am thinking of limiting the first renderer to a small component set (text, card, list, button) rather than attempting full component coverage immediately.

The architecture I am exploring is:

Raw response → schema detection → semantic classification → optional UI renderer → fallback raw preview

My goal is to keep the first version mergeable and extensible rather than broad.

Would this MVP direction align with current expectations for the idea?

[dhairyajangir]

Hey @animator @ashitaprasad , i wanted to share a quick update on my POC.

I have added the Flutter widget layer on top of the parser. So now it not only parses the OpenAI Responses API payload into typed Dart classes but also renders them visually with proper cards for each item type, reasoning, function calls, linked outputs, messages, and a fallback card for anything unknown.

Here is the POC: https://github.com/dhairyajangir/gsoc-poc/tree/poc/dhairya-open-responses-parser/2026/dhairya_open_responses_parser

Would love to hear your thoughts on the approach.

[veyron-kairo]

Hey @animator @ashitaprasad — wanted to share a progress update on the PoC I submitted in PR #1358.

Since my last message here I have been building out the actual implementation rather than just planning it. The PoC now has a typed Dart model layer for Open Responses (sealed classes for all output item types plus a live SSE streaming parser), a structured viewer that renders each item type differently — collapsible reasoning traces, tool calls grouped with their outputs as key-value tables, and markdown bubbles for the final message. There is also an A2UI renderer that parses the JSONL command stream and builds a live Flutter widget tree (15 component types, local state, data binding), and an interactive agent chat view where you type a message and the full agent trace renders inline per turn.

To make it easier to test without running anything locally, I moved the mock server to Vercel — all five endpoints are live at https://apidash-liart.vercel.app. You can hit them directly from APIDash or curl without any setup at all.

The main thing still missing is live token-by-token animation during streaming. The parser handles it already, I just have not wired up the UI update loop yet. That would be the first thing I tackle as the core GSoC deliverable.

Would love any feedback on the direction before the proposal deadline!