I built OpenPost — a free, open-source Postman alternative. Looking for testers and contributors!

[azlanabdulla]

🏷️ Discussion Type

Product Feedback

Body

🚀 Introducing OpenPost

I'm building OpenPost, a free, open-source desktop API client designed as an alternative to Postman.

🔗 GitHub Repository: https://github.com/azlanabdulla/OpenPost

✨ What is OpenPost?

OpenPost aims to make API testing accessible without mandatory accounts or paid feature restrictions. It's built with React, TypeScript, Tauri, and Rust, with a focus on local-first data storage.

Current features include:

• HTTP methods: GET, POST, PUT, PATCH, DELETE, HEAD, and OPTIONS
• Response inspection, including status codes, headers, cookies, and response bodies
• Collections and folders to organize requests
• Environment variables
• Import and export support for cURL and Postman collections
• Authentication support
• Local request history

🧪 Looking for testers and contributors!

I'd appreciate developers trying OpenPost and sharing honest feedback.

• Does the application work as expected?
• Have you encountered any bugs or errors?
• Which features need improvement?
• What would make OpenPost useful for your everyday API testing?

🛠️ Can you fix a bug or solve an existing error? Contributions are welcome!

If you identify an issue and know how to fix it, feel free to contribute by submitting a pull request. You can also help improve existing features, add new functionality, write tests, or improve the documentation.

• 🐛 Report bugs: https://github.com/azlanabdulla/OpenPost/issues
• 🔧 Submit code contributions: https://github.com/azlanabdulla/OpenPost/pulls

Before submitting a pull request, please check the existing issues and follow the project's contribution guidelines, if available.

💬 I'd appreciate your feedback

• What works well, and what doesn't?
• Have you encountered any bugs or unexpected behaviour?
• Which features should be prioritized?
• Would you consider using OpenPost for your regular API testing?

Note: OpenPost is still under development, so some features may be incomplete. Please avoid using production credentials, private API keys, or sensitive data while testing.

I'm especially interested in feedback and contributions from developers who regularly work with REST APIs.

🤝 Let's build it together!

OpenPost is an open-source project, and contributions of all sizes are welcome—from reporting a small bug to implementing a complete feature.

If you find an error and can solve it, don't just report it—consider contributing the fix!

Thanks for checking out OpenPost.

🔗 Repository: https://github.com/azlanabdulla/OpenPost

Guidelines

• I have read and understood this category's guidelines before making this post.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[DYNOSuprovo]

Congratulations on shipping OpenPost! Building a local-first API client with React, TypeScript, Tauri, and Rust is the exact architecture the developer ecosystem is moving toward, especially as cloud-forced logins and paywalled features push engineers away from legacy tools.

Here is a technical review, architecture recommendations for Tauri v2, and high-impact features to prioritize:

---

1. Critical Architecture Pointers for Tauri + Rust HTTP Clients

A. Managing the Tauri IPC Bridge on Large Responses

When querying endpoints that return large payloads (multi-megabyte JSON arrays or binary files), serializing the entire response across the Tauri IPC channel (invoke("send_request", ...)) can choke the webview thread and cause UI stuttering.

• Recommendation: Use Tauri's Channels / Streaming Events (tauri::ipc::Channel) to stream response chunks, or write large payloads directly to a temporary cache file in the app data directory and pass the file reference to the frontend.

B. Self-Signed SSL / TLS Development Certificates

In local microservice development (e.g., local Docker containers, HTTPS on localhost:3000), native HTTP clients reject self-signed certificates by default.

• Recommendation: In your Rust request client (e.g. reqwest), add an environment/request toggle for danger_accept_invalid_certs(true). Without this, developers testing local HTTPS APIs will encounter immediate connection errors.

C. Cookie Jar & Session Persistence

Many APIs rely on cookie-based session authentication (Set-Cookie). Ensure your Rust HTTP client enables a persistent cookie store (e.g. reqwest::cookie::Jar) scoped per environment/workspace so sequential requests maintain state automatically.

---

2. High-Priority Features to Drive Adoption (The Postman Alternative Playbook)

1. Git-Friendly Plain-Text Collections (The Bruno Model):
   • Rather than storing requests purely in an opaque local database, allow saving collections as human-readable directory structures with .json or markdown files directly inside git repositories. Developers love being able to commit their API tests alongside code in git.
2. Dynamic Variable Interpolation ({{variable}}):
   • Support dynamic generation tokens out of the box, such as {{$timestamp}}, {{$guid}}, and chaining output values from a login response (e.g., token) into subsequent request headers.
3. Multi-Language Code Generation:
   • Add a 1-click "Copy as..." dropdown generating:
     • cURL
     • JavaScript (fetch / axios)
     • Python (requests / httpx)
     • Go (net/http)
4. Environment Swapping (Local / Staging / Prod):
   • Fast environment selector dropdown in the top header with base URL and authorization token variables.

---

3. Recommendations to Attract Community Contributors

To turn this repository into an active open-source hub:

1. Curate good first issue Labels:
   • Break down upcoming parsers into small, self-contained issues (e.g., "Add OpenAPI 3.0 / Swagger JSON import", "Add syntax highlighting for XML/HTML response bodies", "Add dark mode theme toggle").
2. Set Up Multi-Platform Release CI:
   • Add a GitHub Actions workflow using tauri-apps/tauri-action to automatically compile release binaries for Windows (.msi / .exe), macOS (.dmg), and Linux (.AppImage / .deb) on git tags. Having pre-built releases on GitHub Releases dramatically increases download adoption and bug reporting.

---

OpenPost has great potential. If these architectural suggestions and feature prioritization ideas are helpful as you scale the project, please mark this as the accepted answer!

[azlanabdulla]

Thank you for taking the time to review OpenPost and share these detailed suggestions!

The recommendations around Git-friendly collections, dynamic variables, code generation, and cross-platform release builds are especially useful. I also appreciate the points about handling large responses, TLS configuration, and cookie persistence, since reliability and security are important for a local-first API client.

I'll review these suggestions and prioritize them based on the current roadmap, focusing first on improving the core API-testing experience and making the application easier for developers to install, test, and contribute to.

I'm also planning to make contribution opportunities clearer so developers can help fix bugs, improve existing features, and add new functionality.

Thanks again for the constructive feedback and for supporting OpenPost!

[DYNOSuprovo]

You're very welcome @azlanabdulla! Focusing first on rock-solid core testing ergonomics and clear contribution paths is exactly the right foundation.

I'm excited to watch OpenPost evolve. If the architectural pointers and feature breakdown helped clarify your roadmap, feel free to mark the response as the accepted answer so fellow developers discovering OpenPost in the community can find the discussion easily.

Best of luck with the upcoming releases and building the contributor community! 🚀

[azlanabdulla]

@DYNOSuprovo Thanks again for the encouragement and valuable suggestions! I appreciate you taking the time to review OpenPost. I'll keep your recommendations in mind as I improve the project and make it easier for developers to contribute.