Freddy Agbona

Freddy Agbona

Writing & Notes

Boosting Product Reliability: How I Built an In-Platform Issue Reporting API for Bolt.new

Improve UX and debug efficiency with a Node.js GitHub-linked issue reporter in Bolt.new. Learn how we built it for non-tech users.

nodejs typescript express api-design github-api bolt-new stackblitz product feedback rest-api octokit testing developer-tools product-reliability
In-platform issue reporting API for Bolt.new

Introduction: From Friction to Feedback

StackBlitz’s Bolt.new is revolutionizing full-stack development in the browser. But one friction point remained: how could non-technical users like designers, PMs, or QA teams report issues without jumping through hoops?

The answer: bring issue reporting into the platform.

In this article, I’ll walk you through how I built a lightweight Node.js REST API that connects Bolt.new directly to GitHub enabling one-click issue reporting, even for non-developers.

The Problem: Silent Failures & Frustrated Users

Before this solution, feedback from non-technical users was inconsistent and fragmented. Most bugs or errors experienced by product stakeholders went unreported or were communicated informally. For example this user created a github account just for submit an issue an he left a long message about his problem without guidance.

This led to:

  • A lack of visibility into recurring issues.

  • Slower bug resolution.

  • A hit to overall user trust and platform reliability.

The Solution: GitHub-Connected Issue Reporting API

I created a TypeScript-based Express API that:

  • Accepts issue reports via a POST endpoint.

  • Validates and structures user-submitted data.

  • Authenticates via GitHub’s API using Octokit.

  • Automatically creates detailed GitHub issues in real-time.

This solution empowers users to report directly from Bolt.new, no GitHub knowledge needed.

Under the Hood

This project was built with production-level tooling and quality standards in mind:

Key Features

  • Zod for request validation (type-safe and runtime safe).

  • Centralized logging and structured error handling.

  • Environment variable validation to avoid silent config errors.

  • Linting + formatting with ESLint, Prettier, Husky and lint-staged.

  • Unit tests with Jest and integration tests using Supertest.

Endpoint Design & Expected Payload

POST /api/report

Request Body (JSON):

{
  "title": "Bug summary",
  "description": "Detailed user-provided description",
  "context": {
    "url": "Bolt.new session link",
    "errors": ["Error stack traces, if any"],
    "actions": ["User steps before the issue"]
  }
}

This payload is translated into a structured GitHub issue with embedded context, accelerating dev triage.

Evolution: Toward a Rich Feedback Interface

While the initial version of the API handled structured text input, the next step is to enrich the user feedback experience by integrating a lightweight markdown or WYSIWYG editor.

This enhancement would allow users to:

  • Format their descriptions with headings, lists, or code blocks.

  • Embed screenshots directly into the issue report (via base64 upload or image hosting).

  • Provide clearer reproduction steps with visual support.

This evolution aligns with our goal of making technical feedback accessible and useful for both technical and non-technical contributors.

Tech Stack & Architecture

Why Node.js + Express?

  • Fast to prototype.

  • Native JSON support.

  • Seamless GitHub API integration.

Why TypeScript?

  • Strong typings for safer, more maintainable code.

  • Helpful for team collaboration and future scaling.

Why Octokit?

  • Official GitHub SDK.

  • Simple authentication and repo interaction.

Project Structure:

bolt-issue-api/
├── src/
│   ├── controllers/reportController.ts
│   ├── routes/reportRoutes.ts
│   ├── services/githubService.ts
│   ├── middleware/
│   │   ├── errorHandler.ts
│   │   └── validate.ts
│   ├── config/index.ts
│   ├── schemas/reportSchema.ts
│   ├── utils/logger.ts
│   └── server.ts
├── tests/
│   ├── services/githubService.test.ts
│   ├── routes/reportRoutes.test.ts
│   ├── utils/logger.test.ts
│   └── middleware/errorHandler.test.ts
├── openapi.yaml
├── .env.example
├── .eslintrc.js
├── .prettierrc
├── .gitignore
├── jest.config.js
├── package.json
├── tsconfig.json
└── README.md

Results: What This Changed

With this integration:

  • Users can now report bugs in 30 seconds or less.

  • Devs get structured, actionable reports in GitHub.

  • PMs and QA teams gain better visibility into platform issues.

This single API reduced debugging turnaround and improved our response time to user pain points dramatically.

Key ScreenShots

POST Request to submit an issue

POST Request to submit an issue

Issues Page from Github

Issues Page from Github

Issue created from api

Issue created from api

Test Execution

Issue created from api

Test Execution

Swagger Documentation

Swagger Documentation

Conclusion

Bolt.new has been one of the most surprising tools in my ongoing comparison series on AI-powered developer platforms. Its browser-first, instant-on approach to fullstack development makes it an excellent playground for quick iterations.

But more importantly, it’s a powerful foundation to build upon. This user feedback API is a concrete example: it solves a real product need, integrates seamlessly into the Bolt.new workflow, and opens the door to more advanced extensions contextual chat, AI assistance, session tracking, and beyond.

As a developer and SaaS builder, I deeply believe in this approach: enhancing the tools we already use with integrated, UX-friendly layers that bring value to all roles not just engineers.

This API is a first brick. If it inspires you, feel free to fork it, extend it, or reach out to discuss it!

I co-wrote another article where we tested bolt.new on a real project with feedback on the advantages and limitations of the tool: read it here.

References & Resources